Amazon Web Services ブログ

お使いの AWS Organization で、サービスコントロールポリシーを使用して、複数アカウントのアクセス許可のガードレールを設定する方法

AWS Organizations では、複数アカウントに対する集中ガバナンスおよび集中マネジメントを提供します。集中セキュリティ管理者の皆さんは AWS Organizations を使用してサービスコントロールポリシー (SCP) を適用することで、IAM プリンシパル (ユーザーおよびロール) が忠実に順守するコントロールを確立しています。今回、SCP を使用して、AWS Identity and Access Management (IAM) ポリシー言語がサポートする精緻なコントロールでアクセス許可のガードレールを設定できることになりました。これにより、ポリシーを微調整して、組織内のガバナンスルールの要件に厳密に適合させることがこれまで以上に簡単になります。

SCP を使用すると、ConditionsResourcesNotAction を指定して、組織全体または組織単位で複数アカウントにわたるアクセスを拒否できます。たとえば、SCP を使って、特定の AWS リージョンへのアクセスを制限できます。また、お客様の集中管理者が使用する IAM ロールのような共有リソースを、IAM プリンシパルが削除できないようにすることも可能です。さらに、お客様のガバナンスコントロールの例外を定義できると同時に、特定の管理者ロールを除いてアカウント内のすべての IAM エンティティ (ユーザー、ロール、ルート) に対するサービスアクションを制限できます。

SCP を使ってアクセス許可のガードレールを運用するには、AWS Organizations コンソールにある新しいポリシーエディタを使用します。このエディタ内でアクション、リソース、条件を追加することで、SCP を簡単に作成できます。この記事では、SCP の概要をご説明し、新機能をご紹介して、さらに皆さんの組織でも今すぐ使えるような SCP のサンプルの作成方法をご覧いただきます。

サービスコントロールポリシーという概念の概要

例をいくつかご紹介する前に、SCP の機能と AWS Organizations について説明します。

SCP は、アカウント内のすべての IAM エンティティに対するアクセス権限を一元管理できる機能を提供します。そのため、皆さんが必要だと考えるアクセス許可を社内の対象者全員に対して施行できます。SCP を使用すると、開発者が自分のアクセス許可を管理する自由度が増しますが、これは開発者のオペレーションが皆さんが定義した境界線内に限られるからです。

SCP は AWS Organizations によって作成、適用します。組織を作成すると、AWS Organizations が自動的にルートを作成します。ルートは組織のすべてのアカウントの親コンテナとなります。ルート内では組織内のアカウントを組織単位 (OU) にグループ化して、アカウント管理を簡素化できます。1 つの組織内に複数の OU を作成できます。また、別の OU 内にさらに OU を作成して、階層構造にもできます。SCP は、組織ルート、OU、各アカウントにアタッチが可能です。ルートにアタッチされた SCP や OU は、すべての OU および OU 内のすべてのアカウントに適用されます。

SCP は AWS Identity and Access Management (IAM) ポリシー言語を使用しますが、アクセス許可そのものは付与しません。SCP では、あるアカウント内の IAM エンティティに対して最大使用アクセス権限を定義することで、アクセス許可のガードレールが設定できます。SCP があるアカウントに対するアクションを拒否した場合は、たとえその IAM 権限が許可していたとしても、当該アカウント内のエンティティはそのアクションの影響を受けません。SCP に設定されたガードレールは、当該アカウント内のすべての IAM エンティティ (ユーザー、ロール、アカウントルートユーザー) に適用されます。

SCP に使用できるポリシーエレメント

SCP に使用できる IAM ポリシー言語エレメントを下表にまとめました。その他の IAM ポリシーエレメントに関する詳細は、IAM JSON ポリシーリファレンスをご覧ください。

サポート対象のステートメント結果 の列は、SCP の各ポリシーエレメントで使用できる効果タイプを示しています。

ポリシーエレメント 定義 サポート対象のステートメント結果
Statement ポリシーのメインエレメント。各ポリシーには複数のステートメントがある場合があります。 Allow、Deny
Sid (オプション) ステートメントの使いやすい名前。 Allow、Deny
Effect SCP ステートメントがアカウント内のアクションを許可するか拒否するかを定義。 Allow、Deny
Action SCP が適用される AWS アクションを一覧表示。 Allow、Deny
NotAction (新) (オプション) SCP から除外される AWS アクションを一覧表示。Action エレメントの代用として使用。 Deny
Resource (新) SCP が適用される AWS リソースを一覧表示。 Deny
Condition (新) (オプション) ステートメントの実行条件を指定。 Deny

注意: 一部ですが、アクションを拒否する SCP のみで使用できるポリシーエレメントがあります。

今回追加されたポリシーエレメントは、お客様の組織内の既存の SCP でも、新規の SCP でも使用できます。次のセクションでは、新しいエレメントを使用して、AWS Organizations コンソールから SCP を作成します。

AWS Organizations コンソールから SCP を作成する

このセクションでは、アカウント内の IAM プリンシパルが、組織内のすべてのアカウントに作成された共通の管理 IAM ロールを変更することを制限する SCP を作成します。皆さんの集中セキュリティチームがこれらのロールを使用して、AWS 設定を監査、変更するとします。この例のために、皆さんはすべてのアカウントに AdminRole という名のロールをお持ちです。このロールには管理ポリシー AdministratorAccess がアタッチされています。SCP を使用すると、アカウント内のすべての IAM エンティティが AdminRole またはその関連のアクセス許可を修正することを制限できます。これで、皆さんの集中セキュリティチームがこのロールをいつでも使用可能な状態にできます。次に、この SCP を作成、アタッチする手順をご覧いただきます。

  1. AWS Organizations コンソールから、AWS Organizations の全機能および SCP を有効にしておきます。
  2. AWS Organizations コンソールから、[Policies] タブ、次に [Create policy] を選択します。
    図 1: [Policies] タブから [Create policy] を選択

    図 1: [Policies] タブから [Create policy] を選択

  3. ポリシーに名前と説明を付けて、すぐに分かるようにします。この例では、次の名前と説明を使用します。
    • 名前: DenyChangesToAdminRole
    • 説明: すべての IAM プリンシパルの AdminRole 変更を阻止。

     

    図 2: ポリシーの名前と説明を決定

    図 2: ポリシーの名前と説明を決定

  4. ポリシーエディタがテキストエディタ内で作業開始できるように、空のステートメントを開きます。カーソルをポリシーステートメント内に置きます。選択したポリシーステートメントの内容をエディタが検知し、関連する [Actions]、[Resources]、[Conditions] を左パネルに追加できるようにします。
    図 3: SCP エディタツール

    図 3: SCP エディタツール

  5. Statement ID を変更して、当該ステートメントの実行内容を決定します。この例では、DenyChangesToAdminRole のポリシー名を再度使用しました。このポリシーにはステートメントが 1 つしかないからです。
    図 4: Statement ID の変更

    図 4: Statement ID の変更

  6. 次に、制限したいアクションを追加します。左パネルから、IAM サービスを選択します。アクション一覧をご覧ください。各アクションの詳細をご覧になるには、見たいアクションの上にマウスを重ねます。この例では、アカウント内のプリンシパルはロールを表示できるが、修正や削除のようなアクションはすべて制限するものとします。ここでは、新しい NotAction ポリシーエレメントを使用して、当該ロールの表示アクションを除くすべてのアクションを拒否するようにします。一覧から次の表示アクションを選択します:
    • GetContextKeysForPrincipalPolicy
    • GetRole
    • GetRolePolicy
    • ListAttachedRolePolicies
    • ListInstanceProfilesForRole
    • ListRolePolicies
    • ListRoleTags
    • SimulatePrincipalPolicy
  7. 今度はカーソルを Action エレメントに合わせて、NotAction に変更します。ここまでのステップが終わったら、ポリシーは以下のようになっているはずです。
    図 5: ポリシー例

    図 5: ポリシー例

  8. 次に、これらの制御をアカウント内の AdminRole だけに適用します。これには、Resource ポリシーエレメントを使用して、特定のリソースを付与できるようにします。
      1. 左側の一番下近くにある [Add Resources] ボタンを選択します。
      2. プロンプトのドロップダウンメニューから、IAM サービスを選択します。
      3. リソースタイプには [Role] を選択し、次にリソース ARN プロンプトでは “arn:aws:iam::*:role/AdminRole” を選択します。
      4. [Add resource] を選択します。

    注意: AdminRole にはすべてのアカウントに共通の名前がありますが、各ロールによってアカウント ID は異なります。ポリシーステートメントを簡素化するには、当該アカウントに関係なくこの名前を持つすべてのロールを対象とするアカウント ID の代わりに、ワイルドカードとして「*」を使用します。

  9. ポリシーは、以下のようになるはずです。
    
    {    
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "DenyChangesToAdminRole",
          "Effect": "Deny",
          "NotAction": [
            "iam:GetContextKeysForPrincipalPolicy",
            "iam:GetRole",
            "iam:GetRolePolicy",
            "iam:ListAttachedRolePolicies",
            "iam:ListInstanceProfilesForRole",
            "iam:ListRolePolicies",
            "iam:ListRoleTags",
            "iam:SimulatePrincipalPolicy"
          ],
          "Resource": [
            "arn:aws:iam::*:role/AdminRole"
          ]
        }
      ]
    }
    
  10. [Save changes] ボタンを選択して、ポリシーを作成します。新しいポリシーは、[Policies] タブで確認できます。
    図 6: [Policies] タブに表示された新しいポリシー

    図 6: [Policies] タブに表示された新しいポリシー

  11. 最後に、アクセス許可を適用したい AWS アカウントにポリシーをアタッチします。

SCP をアタッチすると、SCP が当該ロールの構成の変更を抑止します。当該ロールを使用する集中セキュリティチームは、後日になって変更する必要性が生じ、ロール構成を修正する権限をチームに残しておきたいケースも考えられます。この設定方法を次のセクションでご紹介します。

管理者ロールのための SCP 例外設定

前のセクションでは、すべてのプリンシパルが AdminRole IAM ロールを修正、削除するのを抑止する SCP を作成しました。集中セキュリティチームの管理者であれば、SCP の保護を解除することなく、組織内のこのロールを変更する必要性が生じることも考えられます。次の例では、先ほどのポリシーをベースにして、SCP ガードレールから AdminRole を除外する方法をご覧いただきます。

  1. AWS Organizations コンソールから、[Policies] タブ、[DenyChangesToAdminRole] ポリシー、[Policy editor] の順に選択します。
  2. [Add Condition] を選択します。グローバル条件キー aws:PrincipalARN を使用し、当該ポリシーの Condition エレメントを使用して、ポリシー制限から除外したいロールを指定します。
  3. 条件キー aws:PrincipalARN は、リクエストを実行したプリンシパルの ARN を返します。リクエストしたプリンシパルが AdminRole である場合は、そのポリシーステートメントは無視します。プリンシパルの ARN が AdminRole でない場合は、演算子 StringNotLike を使用して、発効中のこの SCP をアサートします。これには、条件として次の値を指定します。
    1. 条件キー: aws:PrincipalARN
    2. 修飾子: Default
    3. 演算子: StringNotLike
    4. 値: arn:aws:iam::*:role/AdminRole
  4. [Add condition] を選択します。編集ウィンドウに次のポリシーが表示されます。
    
    {    
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "DenyChangesToAdminRole",
          "Effect": "Deny",
          "NotAction": [
            "iam:GetContextKeysForPrincipalPolicy",
            "iam:GetRole",
            "iam:GetRolePolicy",
            "iam:ListAttachedRolePolicies",
            "iam:ListInstanceProfilesForRole",
            "iam:ListRolePolicies",
            "iam:ListRoleTags"
          ],
          "Resource": [
            "arn:aws:iam::*:role/AdminRole"
          ],
          "Condition": {
            "StringNotLike": {
              "aws:PrincipalARN":"arn:aws:iam::*:role/AdminRole"
            }
          }
        }
      ]
    }
    
    
  5. ポリシーを検証して、[Save] を選択します。組織内ですでにポリシーをアタッチ済みである場合は、この変更はただちに発効します。

これで SCP は、アカウント内の AdminRole を除くすべてのプリンシパルが AdminRole を更新、削除するのを拒否します。

次のステップ

今回は SCP を使って、特定のリソースへのアクセスを制限したり、SCP の発効中に条件を定義したりできるようになりました。新機能は今お使いの SCP で今すぐご利用になれます。組織全体に新しいアクセス許可のガードレールを作成することも同様です。このブログ記事では 1 つの例をご紹介しましたが、他にも SCP のユースケースがあります。詳細は、ドキュメントでご覧ください。参考のために、お客様からの声を少しご紹介しておきます。

  • アカウントのオペレーションが、特定の AWS リージョンに限定される ()
  • アカウントがデプロイできるのが、特定の EC2 インスタンスタイプに限定される ()
  • アクション実行以前に、アカウントが多要素認証 (MFA) を要求する ()

SCP の適用は、AWS Organizations コンソールCLIAPIのいずれかを使用して開始できます。SCP の詳細や組織内の使用方法、その他の事例については、サービスコントロールポリシーまたは AWS Organizations Forums をご覧ください。

AWS セキュリティの最新のハウツーコンテンツ、ニュース、新機能発表が必要ですか? Twitterでフォローしてください。

著者について

Michael Switzer

AWS の Identity and Access Management サービスの製品マネージャーです。お客様と直接やりとりしながら、またデータ駆動型の意思決定をしながら、お客様の課題を解決するソリューションを探し出していきます。余暇では、熱烈なサイクリストであり、根っからのアウトドア派です。ワシントン大学で計算数学の修士号を取得しています。