Esempi di policy basate su identità di Amazon API Gateway - Amazon API Gateway
Best practice per le policyConsentire agli utenti di visualizzare le loro autorizzazioniAutorizzazioni di lettura sempliciCreare solo autorizzatori REQUEST o JWTRichiedere che l'endpoint predefinito execute-api sia disabilitatoConsenti agli utenti di creare o aggiornare solo REST privati APIsRichiedere che i route API abbiano l'autorizzazioneImpedisci a un utente di creare o aggiornare un collegamento VPCEsempi di politiche per l'utilizzo delle regole di routing

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Esempi di policy basate su identità di Amazon API Gateway

Per impostazione predefinita, gli utenti e i ruoli IAM non dispongono dell'autorizzazione per creare o modificare le risorse di API Gateway. Inoltre, non possono eseguire attività utilizzando AWS Management Console AWS CLI, o. AWS SDKs Un amministratore IAM deve creare policy IAM che concedono a utenti e ruoli l'autorizzazione per eseguire operazioni API specifiche sulle risorse specificate di cui hanno bisogno. L'amministratore devi quindi collegare queste policy a utenti o IAM che richiedono tali autorizzazioni.

Per informazioni sulla creazione di policy IAM, consulta Creazione di policy nella scheda JSON della Guida per l'utente di IAM. Per informazioni sulle operazioni, le risorse e le condizioni specifiche di API Gateway, consulta Operazioni, risorse e chiavi di condizione per Amazon API Gateway Management e Operazioni, risorse e chiavi di condizione per Amazon API Gateway Management V2.

Best practice per le policy

Le policy basate su identità determinano se qualcuno può creare, accedere o eliminare risorse API Gateway nell'account. Queste azioni possono comportare costi aggiuntivi per l' Account AWS. Quando crei o modifichi policy basate su identità, segui queste linee guida e raccomandazioni:

  • Inizia con le policy AWS gestite e passa alle autorizzazioni con privilegi minimi: per iniziare a concedere autorizzazioni a utenti e carichi di lavoro, utilizza le politiche AWS gestite che concedono le autorizzazioni per molti casi d'uso comuni. Sono disponibili nel tuo. Account AWS Ti consigliamo di ridurre ulteriormente le autorizzazioni definendo politiche gestite dai AWS clienti specifiche per i tuoi casi d'uso. Per ulteriori informazioni, consulta Policy gestite da AWSo Policy gestite da AWS per le funzioni dei processi nella Guida per l'utente IAM.

  • Applica le autorizzazioni con privilegio minimo: quando imposti le autorizzazioni con le policy IAM, concedi solo le autorizzazioni richieste per eseguire un'attività. È possibile farlo definendo le azioni che possono essere intraprese su risorse specifiche in condizioni specifiche, note anche come autorizzazioni con privilegi minimi. Per ulteriori informazioni sull'utilizzo di IAM per applicare le autorizzazioni, consulta Policy e autorizzazioni in IAM nella Guida per l'utente IAM.

  • Condizioni d'uso nelle policy IAM per limitare ulteriormente l'accesso: per limitare l'accesso a operazioni e risorse è possibile aggiungere una condizione alle tue policy. Ad esempio, è possibile scrivere una condizione di policy per specificare che tutte le richieste devono essere inviate utilizzando SSL. Puoi anche utilizzare le condizioni per concedere l'accesso alle azioni del servizio se vengono utilizzate tramite uno specifico Servizio AWS, ad esempio AWS CloudFormation. Per ulteriori informazioni, consulta la sezione Elementi delle policy JSON di IAM: condizione nella Guida per l'utente IAM.

  • Utilizzo di IAM Access Analyzer per convalidare le policy IAM e garantire autorizzazioni sicure e funzionali: IAM Access Analyzer convalida le policy nuove ed esistenti in modo che aderiscano alla sintassi della policy IAM (JSON) e alle best practice di IAM. IAM Access Analyzer offre oltre 100 controlli delle policy e consigli utili per creare policy sicure e funzionali. Per ulteriori informazioni, consulta Convalida delle policy per il Sistema di analisi degli accessi IAM nella Guida per l'utente IAM.

  • Richiedi l'autenticazione a più fattori (MFA): se hai uno scenario che richiede utenti IAM o un utente root nel Account AWS tuo, attiva l'MFA per una maggiore sicurezza. Per richiedere la MFA quando vengono chiamate le operazioni API, aggiungi le condizioni MFA alle policy. Per ulteriori informazioni, consulta Protezione dell'accesso API con MFA nella Guida per l'utente IAM.

Per maggiori informazioni sulle best practice in IAM, consulta Best practice di sicurezza in IAM nella Guida per l'utente di IAM.

Consentire agli utenti di visualizzare le loro autorizzazioni

Questo esempio mostra in che modo è possibile creare una policy che consente agli utenti IAM di visualizzare le policy inline e gestite che sono cpllegate alla relativa identità utente. Questa policy include le autorizzazioni per completare questa azione sulla console o utilizzando programmaticamente l'API o. AWS CLI 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": "*"
        }
    ]
}

Autorizzazioni di lettura semplici

Questa politica di esempio fornisce all'utente il permesso di ottenere informazioni su tutte le risorse di un HTTP o di un' WebSocket API con l'identificatore di a123456789 nella AWS regione us-east-1. La risorsa arn:aws:apigateway:us-east-1::/apis/a123456789/* include tutte le risorse secondarie dell'API, ad esempio autorizzatori e distribuzioni.

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

Creare solo autorizzatori REQUEST o JWT

Questa politica di esempio consente a un utente di creare solo REQUEST o APIs con JWT autorizzatori, anche tramite importazione. Nella sezione Resource della policy, arn:aws:apigateway:us-east-1::/apis/?????????? richiede che le risorse abbiano un massimo di 10 caratteri, che escludono le risorse secondarie di un'API. Questo esempio utilizza ForAllValues nella sezione Condition perché gli utenti possono creare più autorizzatori contemporaneamente importando un'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"
          ]
        }
      }
    }
  ]
}

Richiedere che l'endpoint predefinito execute-api sia disabilitato

Questa policy di esempio consente agli utenti di creare, aggiornare o importare un'API, con il requisito che DisableExecuteApiEndpoint sia true. Quando DisableExecuteApiEndpoint è true, i client non possono utilizzare l'endpoint execute-api predefinito per richiamare un'API.

Usiamo la condizione BoolIfExists per gestire una chiamata per aggiornare un'API che non ha la chiave di condizione DisableExecuteApiEndpoint popolata. Quando un utente tenta di creare o importare un'API, la chiave di condizione DisableExecuteApiEndpoint viene sempre popolata.

Poiché la apis/* risorsa acquisisce anche risorse secondarie come autorizzatori o metodi, la esaminiamo esplicitamente solo con una dichiarazione. APIs 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/*/*"
      ]
    }
  ]
}

Consenti agli utenti di creare o aggiornare solo REST privati APIs

Questa policy di esempio utilizza le chiavi di condizione per richiedere che un utente crei solo PRIVATE APIs e per impedire aggiornamenti che potrebbero modificare un'API da PRIVATE un altro tipo, ad esempioREGIONAL.

Utilizziamo ForAllValues per richiedere che ogni EndpointType aggiunto a un'API sia PRIVATE. Utilizziamo una chiave di condizione delle risorse per consentire qualsiasi aggiornamento a un'API fino a quando è PRIVATE. ForAllValues si applica soltanto quando è presente una chiave di condizione.

Utilizziamo il non-greedy matcher (?) per abbinarlo esplicitamente all'API per impedire l'utilizzo di risorse non API IDs come gli autorizzatori.

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/*"
            ]
        }
    ]
}

Richiedere che i route API abbiano l'autorizzazione

Questa policy fa sì che i tentativi di creare o aggiornare un route (anche attraverso l'importazione) non riescono se il route non dispone di autorizzazione. ForAnyValue restituisce false se la chiave non è presente, ad esempio quando un route non viene creato o aggiornato. Usiamo ForAnyValue perché più route possono essere creati attraverso l'importazione.

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"
        }
      }
    }
  ]
}

Questa policy impedisce a un utente di creare o aggiornare un collegamento VPC. Un collegamento VPC consente di esporre risorse all'interno di Amazon VPC ai client esterni a 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/*"
      ]
    }
  ]
}

Esempi di politiche per l'utilizzo delle regole di routing

Le politiche di esempio seguenti mostrano come utilizzare i tasti di RoutingRule condizione per controllare in che modo gli utenti possono indirizzare il traffico dai loro nomi di dominio personalizzati al loro REST APIs. È possibile utilizzare questi esempi per creare politiche dettagliate relative al tipo di regole di routing che gli utenti possono stabilire. Per ulteriori informazioni, consulta Regole di routing per connettere le fasi dell'API a un nome di dominio personalizzato per REST APIs.

Impedisci a un utente di modificare il modo in cui un nome di dominio personalizzato indirizza una richiesta

Questa politica impedisce a un utente di creare o aggiornare unBasePathMapping, ApiMapping oRoutingRule. Tutte queste risorse potrebbero modificare il modo in cui un nome di dominio personalizzato indirizza le richieste 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/*"
      ]
    }
  ]
}

Consenti a un utente di aggiornare una regola di routing per determinate priorità

Questa politica consente a un utente di aggiornare una regola di routing solo a una priorità compresa tra 1001 e 2000. È possibile utilizzare questa regola per separare le regole di produzione dalle regole con priorità inferiore e quindi consentire agli utenti di modificare le regole con priorità inferiore senza influire sulle regole di produzione.

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
        } 
      }
    }
  ]
}

Consenti a un utente di aggiornare una regola di routing o la mappatura del percorso di base per un determinato valore del percorso di base

Questa politica consente a un utente di aggiornare solo una mappatura del percorso di base per qualsiasi percorso di base che inizia con orders o di aggiornare una regola di routing corrispondente a un percorso di base che inizia con. orders In questa politica, un utente può aggiornare una mappatura del percorso di base o una regola di routing per orders/create ororders123, ma non. 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"             
          }
        }
      }
  ]
}

Consenti a un utente di aggiornare la modalità di routing a valori specifici

Questa politica consente a un utente di aggiornare la modalità di routing solo a API_MAPPING_ONLY e. ROUTING_RULE_THEN_API_MAPPING Per ulteriori informazioni sulla modalità di routing, vedere. Imposta la modalità di routing per il tuo nome di dominio personalizzato

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*"
               }
           }
       }
    ]
}