AWSメンバーアカウントに対するAPI Gateway権限制御の事例

クラウドインテグレーション事業部の小倉です。
以前はオンプレミスのシステム開発に従事していましたが、ここ数年はAWS基盤を運用しています。

運用改善の一環として、AWS Organizations環境下のメンバーアカウントに対して、API Gatewayの権限制御方法を考える機会がありました。その結果、採用した方法と、検討・検証プロセスをご紹介します。

AWS基盤の、効果的な運用改善に繋がる方法を検討している方の参考になったら嬉しいです。

要件

権限制御の対象となるのは、AWS Organizationsで管理されているメンバーアカウントの開発者です。各アプリ開発者チームに対しそれぞれ専用のメンバーアカウントを割り当て、Service Control Policy（以下、SCP）を用いて予防的統制を中心にセキュリティ・コンプライアンス対策をしています。特に顧客からの要望で、発見的統制よりも予防的統制を強化する方向で進めています。

具体的には下記の要件で制御を適用しています。

• AWS OrganizationsのOUに対してSCPを用いて制限を行う
• SCPはDenyリスト形式（既にOUがDenyリスト形式で稼働中のため）
• 制限対象の各開発者チームには、SCPが適用された専用メンバーアカウントを割り当て自由に使ってもらう
• インターネット向けに公開する設定のリソースは、管理者チームがセキュリティリスクなどを確認した上でデプロイする

各サービスに対するSCPの設計を改善するにあたり、特にAPI Gatewayは制御にひと癖あったため制御方法に悩みました。API Gatewayは基本的にはインターネット向けに公開されるリソースなので、上記要件の通り管理者チームがセキュリティリスクを確認した上でデプロイする必要があります。しかし、開発中に頻繁に更新するリソースでもあるため、管理者チームがすべての操作を代行するのは大きな負担となります。検討の結果、API Gatewayの権限制御の間を突き、デプロイ・ステージ設定のみを操作不可にする実装を行いました。

API Gatewayの権限制御は他となにが違うのか

前段で「API Gatewayの権限制御はひと癖ある」と書きました。具体的な実装の紹介に入る前に、まずは他サービスの権限制御とAPI Gatewayの権限制御はどのように違うのかを説明します。

他サービスの権限制御

多くのAWSサービスのIAMポリシードキュメントは、"Action"が具体的な操作ベース（インスタンスを起動する、バケット作成する、など）と定義されています。それに対してAllowやDenyなどを定義し、権限を制御していきます。

例：
ec2:RunInstances（EC2インスタンスを起動する）
s3:CreateBucket（S3バケット作成する）など

Amazon EC2 のアクション、リソース、および条件キー - サービス認可リファレンス

Amazon S3 のアクション、リソース、条件キー - サービス認可リファレンス

下記のポリシーは、パブリックIPを有効にしたEC2の起動を禁止する権限制御の例です。

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:*:ec2:*:*:network-interface/*",
  "Condition": {
    "Bool": {
      "ec2:AssociatePublicIpAddress": "true"
    }
  }
}

Condition（条件）で、ec2:AssociatePublicIpAddress（パブリックIPアドレス関連付け）がtrueになっているENIに対して、ec2:RunInstances（EC2インスタンスを起動する）をDenyしています。

API Gatewayの権限制御

API GatewayのIAMポリシードキュメントは、"Action"がAWS側のAPIに対してのHTTPメソッドベース（GET,POST,PUT,DELETEなど）で定義されています。

例：
apigateway:POST（POSTリクエスト）
apigateway:DELETE（DELETEリクエスト）

Amazon API Gateway Management のアクション、リソース、および条件キー

そのため、他のサービスの例で挙げた「インスタンスを起動する」や「バケットを作成する」のように、「APIをデプロイする」などの具体的な操作を制限の対象にできません。API Gatewayでは、POSTリクエストやDELETEリクエストなどのHTTPメソッドが制限の対象になるため、設定を誤ると意図しない範囲まで制限が及んでしまう可能性があります。また、制御対象の絞り込みもAWS側のメソッドのパスに従って行うため、AWS側のパス設計に依存することになります。

意図しない範囲まで制限が及んでしまう例としては、「全"resources（API Gatewayの設定項目としてのresourcesを指しています）"に対するDELETE,POST,PUTのActionを制限したい」ときに、下記のようなポリシーを書いてしまった場合です。resourcesに対してのみ制限を行いたいのに、resourcesのパスの下に含まれる「全"methods（API Gatewayの設定項目としてのmethodsを指しています）"に対するDELETE,POST,PUT」まで制限してしまうことになります。

{
    "Effect": "Deny",
    "Action": [
        "apigateway:DELETE",
        "apigateway:POST",
        "apigateway:PUT"
    ],
    "Resource": "arn:${Partition}:apigateway:${Region}::/restapis/${RestApiId}/resources/*"
}

上記ポリシーで制限の対象にしているのは下記resourcesのパスで、全リソースを対象にするためにResourceIdをワイルドカードで指定しています。

以下のresourcesのパス対して、

arn:${Partition}:apigateway:${Region}::/restapis/${RestApiId}/resources/${ResourceId}

methodsのパスはresourcesのパスの下に存在しています。

arn:${Partition}:apigateway:${Region}::/restapis/${RestApiId}/resources/${ResourceId}/methods/${HttpMethodType}

つまり、全resourcesを対象にしようと考え${ResourceId}を*（ワイルドカード）にして制限してしまうと、methodsのパスにも一致してしまい、同様に制限してしまうことになります。

Amazon API Gateway Management で定義されるリソースタイプ

実装した内容

各開発者に付与するIAMポリシーでは、具体的な対象リソースをID指定して細かく権限を制御できますが、今回はSCPを使用してメンバーアカウント全体への制御を適用し、制御の範囲内で操作をさせることが条件です。そのため、個別の開発者や環境に合わせた細かい制御はできません。

また、SCPは文字数制限やOUごとのアタッチ数制限などが厳しいので、あまり細かい制御や環境ごとの例外設定は避けるべきです。そこで、下記を念頭に置いた設計にする必要があります。

• 具体的なリソースIDなどによる制限はできない
• AWS側のHTTPメソッドのパス設計を考慮する
• あまり長いポリシーは書かない

設計

検討の結果、下記の設計としました。

• APIパス"deployments"と"stages"に対する変更を伴うアクション（GET以外）をdenyする
• 管理者チーム権限のARNを例外としてConditionに設定する

ポリシー内容

ポリシー設計は以下の通りです。"deployments"はAPIをデプロイしてステージに反映する操作のパス、"stages"はデプロイしたステージに対する操作のパスです。

{
    "Sid": "API Gateway Restrict Deploy",
    "Effect": "Deny",
    "Action": [
        "apigateway:DELETE",
        "apigateway:PATCH",
        "apigateway:POST",
        "apigateway:PUT"
    ],
    "Resource": [
        "arn:aws:apigateway:*::/*/deployments/*",
        "arn:aws:apigateway:*::/*/deployments",
        "arn:aws:apigateway:*::/*/stages/*",
        "arn:aws:apigateway:*::/*/stages"
    ],
    "Condition": {
        "StringNotLike": {
            "aws:PrincipalArn": [
                "管理者チームの権限ARN"
            ]
        }
    }
}

動作

開発者は自由にAPI Gatewayやリソース、メソッドの作成・変更を行えます。しかし、「デプロイして実環境に反映」「デプロイ後のステージの設定変更」などの操作はできません。

API Gatewayはデプロイ後のステージにアクセスすることで動作するため、管理者チームがこのステージを握っていれば、あとは開発者が自由に操作して問題ありません。デプロイ時には、管理者チームがセキュリティリスクなどを確認した上で実施します。デプロイ後のステージに対しての変更操作も同様です。

動作検証

上記のポリシーを適用してみて、意図した制限ができているか検証を行います。なお、検証環境の都合により、検証はスイッチロールにより行います。ポリシーはSCPではなく疑似SCPとして許可の境界に設定しました。

スイッチ先ロールの設定

ポリシーにAPI Gatewayの全操作権限、許可の境界に疑似SCPを設定します。

許可ポリシー：AmazonAPIGatewayAdministrator
許可の境界：以下の通り

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        },
        {
            "Sid": "APIGatewayRestrictDeploy",
            "Effect": "Deny",
            "Action": [
                "apigateway:DELETE",
                "apigateway:PATCH",
                "apigateway:POST",
                "apigateway:PUT"
            ],
            "Resource": [
                "arn:aws:apigateway:*::/*/deployments/*",
                "arn:aws:apigateway:*::/*/deployments",
                "arn:aws:apigateway:*::/*/stages/*",
                "arn:aws:apigateway:*::/*/stages",
            ]
        }
    ]
}

※ 直接ロールに対して設定するので、Conditionの例外権限の除外設定は省略しました。

意図した制限ができているか動作確認

上記ロールにスイッチしてAPI Gatewayの動作を検証してみます。

API Gatewayの作成・変更・削除

これらはすべて操作可能です。

リソースの作成・変更・削除

こちらもすべて操作可能です。

メソッドの作成・変更・削除

すべて操作可能ですね、意図した操作ができることを確認しました。では、制限したい操作を確認していきます。

デプロイ

ちゃんと拒否されました。

ステージの作成・変更・削除

ステージに対する操作についても、制限できていることを確認しました。

おわりに

SCPでAPI Gatewayに対する操作を制御した一例をご紹介しました。Organizations環境の管理をしている方には、SCPを用いてOU全体に強制的に制御を適用した事例として、ご活用いただければと思います。

また、今回のケースは顧客の要望が強く影響した例でしたが、一般的には個別の開発者ロールごとに設計された権限を付与するケースが多いと思います。そのような場合でもAPI Gatewayの特殊な権限制御に対応する場面はあると思うので、ぜひ参考にしてみてください。

プロフィール