Exemplos de políticas baseadas em identidade do Amazon API Gateway - Amazon API Gateway

Exemplos de políticas baseadas em identidade do Amazon API Gateway

Por padrão, os usuários e as funções do IAM não têm permissão para criar ou modificar recursos do API Gateway. Eles também não podem executar tarefas usando o AWS Management Console, a AWS CLI ou SDKs da AWS. Um administrador do IAM deve criar políticas do IAM que concedam aos usuários e funções permissão para executarem operações de API específicas nos recursos especificados de que precisam. O administrador deve anexar essas políticas aos usuários ou grupos do IAM que exigem essas permissões.

Para obter informações sobre como criar políticas do IAM, consulte Como criar políticas na guia JSON no Guia do usuário do IAM. Para obter informações sobre ações, recursos e condições específicas do API Gateway, consulte Ações, recursos e chaves de condição do Amazon API Gateway Management e Ações, recursos e chaves de condição do Amazon API Gateway Management V2.

Práticas recomendadas de política

As políticas baseadas em identidade determinam se alguém pode criar, acessar ou excluir recursos do API Gateway em sua conta. Essas ações podem incorrer em custos para sua Conta da AWS. Ao criar ou editar políticas baseadas em identidade, siga estas diretrizes e recomendações:

  • Comece com as políticas gerenciadas pela AWS e avance para as permissões de privilégio mínimo: para começar a conceder permissões a seus usuários e workloads, use as políticas gerenciadas pela AWS, que concedem permissões para muitos casos de uso comuns. Elas estão disponíveis em seus Conta da AWS. Recomendamos que você reduza ainda mais as permissões definindo políticas gerenciadas pelo cliente da AWS que são específicas para seus casos de uso. Para obter mais informações, consulte Políticas gerenciadas pela AWS ou Políticas gerenciadas pela AWS para funções de trabalho no Guia do usuário do IAM.

  • Aplique permissões de privilégio mínimo: ao definir permissões com as políticas do IAM, conceda apenas as permissões necessárias para executar uma tarefa. Você faz isso definindo as ações que podem ser executadas em recursos específicos sob condições específicas, também conhecidas como permissões de privilégio mínimo. Para obter mais informações sobre como usar o IAM para aplicar permissões, consulte Políticas e permissões no IAM no Guia do usuário do IAM.

  • Use condições nas políticas do IAM para restringir ainda mais o acesso: você pode adicionar uma condição às políticas para limitar o acesso a ações e recursos. Por exemplo, você pode escrever uma condição de política para especificar que todas as solicitações devem ser enviadas usando SSL. Também pode usar condições para conceder acesso a ações de serviço, se elas forem usadas por meio de um AWS service (Serviço da AWS) específico, como o AWS CloudFormation. Para obter mais informações, consulte Elementos da política JSON do IAM: condição no Guia do usuário do IAM.

  • Use o IAM Access Analyzer para validar suas políticas do IAM a fim de garantir permissões seguras e funcionais: o IAM Access Analyzer valida as políticas novas e existentes para que elas sigam a linguagem de política do IAM (JSON) e as práticas recomendadas do IAM. O IAM Access Analyzer oferece mais de cem verificações de política e recomendações práticas para ajudar a criar políticas seguras e funcionais. Para obter mais informações, consulte Validação de políticas do IAM Access Analyzer no Guia do Usuário do IAM.

  • Exigir autenticação multifator (MFA): se houver um cenário que exija usuários do IAM ou um usuário raiz em sua Conta da AWS, ative a MFA para obter segurança adicional. Para exigir MFA quando as operações de API forem chamadas, adicione condições de MFA às suas políticas. Para obter mais informações, consulte Configuração de acesso à API protegido por MFA no Guia do Usuário do IAM.

Para obter mais informações sobre as práticas recomendadas do IAM, consulte Práticas recomendadas de segurança no IAM no Guia do usuário do IAM.

Permitir que os usuários visualizem suas próprias permissões

Este exemplo mostra como criar uma política que permita que os usuários do IAM visualizem as políticas gerenciadas e em linha anexadas a sua identidade de usuário. Essa política inclui permissões para concluir essa ação no console ou de forma programática usando a AWS CLI ou a API da AWS.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] }

Permissões de leitura simples

Esta política de exemplo concede permissão ao usuário para obter informações sobre todos os recursos de uma API HTTP ou WebSocket com o identificador de a123456789 na região us-east-1 da AWS. O recurso arn:aws:apigateway:us-east-1::/apis/a123456789/* inclui todos os sub-recursos da API, como autorizadores e implantações.

JSON
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "apigateway:GET" ], "Resource": [ "arn:aws:apigateway:::/apis/a123456789/*" ] } ] }

Crie apenas os autorizadores REQUEST ou JWT

Esta política de exemplo permite que um usuário crie APIs apenas com os autorizadores REQUEST ou JWT, inclusive por meio da importação. Na seção Resource da política, o arn:aws:apigateway:us-east-1::/apis/?????????? exige que os recursos tenham um máximo de dez caracteres, o que exclui os sub-recursos de uma API. Este exemplo usa ForAllValues na seção Condition porque os usuários podem criar vários autorizadores de uma só vez importando uma API.

JSON
{ "Version": "2012-10-17", "Statement": [ { "Sid": "OnlyAllowSomeAuthorizerTypes", "Effect": "Allow", "Action": [ "apigateway:PUT", "apigateway:POST", "apigateway:PATCH" ], "Resource": [ "arn:aws:apigateway:us-east-1::/apis", "arn:aws:apigateway:us-east-1::/apis/??????????", "arn:aws:apigateway:us-east-1::/apis/*/authorizers", "arn:aws:apigateway:us-east-1::/apis/*/authorizers/*" ], "Condition": { "ForAllValues:StringEqualsIfExists": { "apigateway:Request/AuthorizerType": [ "REQUEST", "JWT" ] } } } ] }

Exija que o endpoint padrão execute-api esteja desabilitado

Esta política de exemplo permite que os usuários criem, atualizem ou importem uma API, com a exigência de que o DisableExecuteApiEndpoint seja true. Quando o DisableExecuteApiEndpoint for true, os clientes não poderão usar o endpoint padrão execute-api para invocar uma API.

Nós usamos a condição BoolIfExists para lidar com uma chamada para atualizar uma API que não tenha a chave de condição DisableExecuteApiEndpoint preenchida. Quando um usuário tenta criar ou importar uma API, a chave de condição DisableExecuteApiEndpoint é sempre preenchida.

Como o recurso apis/* também captura sub-recursos, como autorizadores ou métodos, nós o estendemos explicitamente apenas para APIs com uma declaração Deny.

JSON
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DisableExecuteApiEndpoint", "Effect": "Allow", "Action": [ "apigateway:PATCH", "apigateway:POST", "apigateway:PUT" ], "Resource": [ "arn:aws:apigateway:us-east-1::/apis", "arn:aws:apigateway:us-east-1::/apis/*" ], "Condition": { "BoolIfExists": { "apigateway:Request/DisableExecuteApiEndpoint": true } } }, { "Sid": "ScopeDownToJustApis", "Effect": "Deny", "Action": [ "apigateway:PATCH", "apigateway:POST", "apigateway:PUT" ], "Resource": [ "arn:aws:apigateway:us-east-1::/apis/*/*" ] } ] }

Permita que usuários criem ou atualizem apenas APIs REST privadas

Esta política de exemplo usa chaves de condição para exigir que um usuário crie somente APIs PRIVATE e para evitar atualizações que possam alterar uma API PRIVATE para outro tipo, como REGIONAL.

Usamos ForAllValues para exigir que cada EndpointType adicionado a uma API seja PRIVATE. Usamos uma chave de condição de recurso para permitir qualquer atualização em uma API, desde que seja PRIVATE. ForAllValues aplica-se somente quando uma chave de condição está presente.

Nós usamos a correspondência não greedy (?) para corresponder explicitamente aos IDs de API para evitar a permissão de recursos que não sejam APIs, como, por exemplo, autorizadores.

JSON
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ScopePutToPrivateApis", "Effect": "Allow", "Action": [ "apigateway:PUT" ], "Resource": [ "arn:aws:apigateway:us-east-1::/restapis", "arn:aws:apigateway:us-east-1::/restapis/??????????" ], "Condition": { "ForAllValues:StringEquals": { "apigateway:Resource/EndpointType": "PRIVATE" } } }, { "Sid": "ScopeToPrivateApis", "Effect": "Allow", "Action": [ "apigateway:DELETE", "apigateway:PATCH", "apigateway:POST" ], "Resource": [ "arn:aws:apigateway:us-east-1::/restapis", "arn:aws:apigateway:us-east-1::/restapis/??????????" ], "Condition": { "ForAllValues:StringEquals": { "apigateway:Request/EndpointType": "PRIVATE", "apigateway:Resource/EndpointType": "PRIVATE" } } }, { "Sid": "AllowResourcePolicyUpdates", "Effect": "Allow", "Action": [ "apigateway:UpdateRestApiPolicy" ], "Resource": [ "arn:aws:apigateway:us-east-1::/restapis/*" ] } ] }

Exija que as rotas da API tenham autorização

Esta política faz com que as tentativas de criação ou atualização de uma rota (inclusive por meio da importação) falhem se a rota não tiver autorização. O ForAnyValue considera a tentativa falsa se a chave não estiver presente, como, por exemplo, quando uma rota não está sendo criada ou atualizada. Nós usamos ForAnyValue porque várias rotas podem ser criadas por meio da importação.

JSON
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowUpdatesOnApisAndRoutes", "Effect": "Allow", "Action": [ "apigateway:POST", "apigateway:PATCH", "apigateway:PUT" ], "Resource": [ "arn:aws:apigateway:us-east-1::/apis", "arn:aws:apigateway:us-east-1::/apis/??????????", "arn:aws:apigateway:us-east-1::/apis/*/routes", "arn:aws:apigateway:us-east-1::/apis/*/routes/*" ] }, { "Sid": "DenyUnauthorizedRoutes", "Effect": "Deny", "Action": [ "apigateway:POST", "apigateway:PATCH", "apigateway:PUT" ], "Resource": [ "arn:aws:apigateway:us-east-1::/apis", "arn:aws:apigateway:us-east-1::/apis/*" ], "Condition": { "ForAnyValue:StringEqualsIgnoreCase": { "apigateway:Request/RouteAuthorizationType": "NONE" } } } ] }

Esta política impede que um usuário crie ou atualize um link da VPC. Um link da VPC permite que você exponha recursos em uma Amazon VPC para clientes fora da VPC.

JSON
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyVPCLink", "Effect": "Deny", "Action": [ "apigateway:POST", "apigateway:PUT", "apigateway:PATCH" ], "Resource": [ "arn:aws:apigateway:us-east-1::/vpclinks", "arn:aws:apigateway:us-east-1::/vpclinks/*" ] } ] }

Exemplos de políticas para usar regras de roteamento

As políticas de exemplo a seguir mostram como usar as chaves de condição RoutingRule para controlar como os usuários podem rotear o tráfego de seus nomes de domínio personalizados para suas APIs REST. Você pode usar esses exemplos para criar políticas granulares para o tipo de regras de roteamento que os usuários podem criar. Para obter mais informações, consulte Regras de roteamento para associar estágios da API a um nome de domínio personalizado para APIs REST.

Impedir que um usuário altere a forma como um nome de domínio personalizado encaminha uma solicitação

Essa política impede que um usuário crie ou atualize BasePathMapping, ApiMapping ou RoutingRule. Todos esses recursos podem mudar a maneira como um nome de domínio personalizado encaminha solicitações para as APIs.

JSON
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyAccessBasePathMappingsApiMappingsRoutingRules", "Effect": "Deny", "Action": "apigateway:*", "Resource": [ "arn:aws:apigateway:us-east-1::/domainnames/example.com/basepathmappings/*", "arn:aws:apigateway:us-east-1::/domainnames/example.com/apimappings/*", "arn:aws:apigateway:us-east-1:111122223333:/domainnames/example.com/routingrules/*" ] } ] }

Permitir que um usuário atualize uma regra de roteamento para determinadas prioridades

Essa política permite que um usuário atualize somente uma regra de roteamento para uma prioridade entre 1001 e 2000. Você pode usar essa regra para separar suas regras de produção das regras de menor prioridade e, em seguida, permitir que os usuários modifiquem as regras de menor prioridade sem afetar as regras de produção.

JSON
{ "Version": "2012-10-17", "Statement": [ { "Sid": "UpdatingRoutingRulePriorityBetween1001And2000", "Effect": "Allow", "Action": "apigateway:UpdateRoutingRule", "Resource": "arn:aws:apigateway:us-east-1:111122223333:/domainnames/example.com/routingrules/*", "Condition": { "NumericGreaterThanEquals": { "apigateway:Resource/Priority": 1001, "apigateway:Request/Priority": 1001 }, "NumericLessThanEquals": { "apigateway:Resource/Priority": 2000, "apigateway:Request/Priority": 2000 } } } ] }

Permitir que um usuário atualize uma regra de roteamento ou mapeamento do caminho base para um determinado valor do caminho base

Essa política permite que um usuário atualize somente um mapeamento de caminho base para qualquer caminho base que comece com orders ou atualize uma regra de roteamento correspondente a um caminho base que comece com orders. Nessa política, um usuário pode atualizar um mapeamento de caminho base ou regra de roteamento para orders/create ou orders123, mas não payment/orders.

JSON
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowUpdateRoutingRuleUnderPathOrders", "Effect": "Allow", "Action": "apigateway:UpdateRoutingRule", "Resource": "arn:aws:apigateway:us-east-1:111122223333:/domainnames/example.com/routingrules/*", "Condition": { "ForAllValues:StringLike": { "apigateway:Request/ConditionBasePaths": ["orders*"], "apigateway:Resource/ConditionBasePaths": ["orders*"] }, "Null":{ "apigateway:Request/ConditionBasePaths":"false", "apigateway:Resource/ConditionBasePaths":"false" } } } ] }

Permitir que um usuário atualize o modo de roteamento para valores específicos

Essa política permite que um usuário atualize somente o modo de roteamento para API_MAPPING_ONLY e ROUTING_RULE_THEN_API_MAPPING. Para obter mais informações sobre o modo de roteamento, consulte Definir o modo de roteamento para o nome de domínio personalizado.

JSON
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowUpdateRoutingModeToAnythingWithApiMapping", "Effect": "Allow", "Action": ["apigateway:PATCH"], "Resource": "arn:aws:apigateway:us-east-1:111122223333:/domainnames/example.com", "Condition": { "StringLike": { "apigateway:Request/RoutingMode":"*API_MAPPING*" } } } ] }