クラウドネイティブを学ぼう！

AWS IAM インラインポリシーとマネージドポリシーの比較

SHARE:

AWS Identity and Access Management（IAM）ポリシーは、アマゾン ウェブ サービス（AWS）環境内のリソース間の相互作用を可能にし、外部からのアクセスを制御する上で極めて重要です。本記事では、利用可能な各種IAMポリシーの種類を検証し、それぞれの仕組みを説明するとともに、それらの固有の差異について探求します。本記事をお読みいただくことで、異なるポリシーの種類と、ご自身のニーズに合った適切なポリシータイプを選択するためのガイドラインについて、より深くご理解いただけるでしょう。

AWS IAM インラインポリシーとマネージドポリシーの比較

学ぶ内容

  • 利用可能なAWSのIAMポリシーの種類

  • 組織に適したAWS IAMポリシーの選び方

AWS IAM 識別子とは？

IAM ポリシーは、AWS リソースに対する一連のアクセス制御を定義します。これらのポリシーを識別子にアタッチすることで、その識別子へのアクセスを許可または拒否します。AWS は複数の識別子タイプをサポートしています。

ユーザー

ユーザー識別子は単一のエンティティを表します。このユーザーは、管理者が AWS アカウントで設定する人間またはマシンユーザーです。ユーザーにポリシーを追加することは可能ですが、これは非常に細かいアプローチであり、スケーラビリティに優れていません。

ユーザーグループ

ユーザーグループは、大規模なユーザー管理の効率を向上させます。管理者、開発者、テスト、製品などのユーザーグループを定義できます。ユーザーグループレベルでIAMポリシーを制御することで、ユーザーをグループに追加するだけで、そのグループのポリシーが即時に適用されます。ユーザーを複数のグループに割り当てることも可能です。

ロール

ロールはユーザーと似ていますが、エンティティに権限を割り当てるために使用されます。EC2インスタンスのオートスケーリンググループ（ASG）を例に考えてみましょう。ASGのサイズが変化すると、インスタンスが作成される場合があります。そのインスタンスをサポートするために新しいユーザーを作成することは、大規模環境では現実的ではありません。代わりに、新しいインスタンスには、その存続期間中に割り当てられるすべての権限を定義したロールが割り当てられます。

識別情報（ユーザー、ユーザーグループ、ロール）を作成後、それらに異なるポリシーを割り当てます。AWSはこれらのポリシーを総合的に評価し、アクションを許可するか拒否するかを決定します。最終的な判断は適用された全ポリシーの交差部分に基づきます。つまり、あるポリシーがアクションを許可しても、別のポリシーが明示的に拒否している場合、そのアクションは拒否されます。

利用可能なポリシーの種類

作成するポリシーの種類は、いくつかの要因によって異なります。また、すべてのアプリケーションに最適な単一のポリシータイプは存在しません。選択可能な異なるポリシータイプは以下の通りです：

  • インラインポリシー
  • マネージドポリシー
  • カスタマー管理ポリシー

インラインポリシーは、ポリシーとユーザーまたはグループとの間に直接的な一対一の関係が存在する場合に適用されます。通常、インラインポリシーは適切な選択肢とは言えませんが、使用したい場合もあるでしょう。以下で詳細に説明し、いくつかの使用例をご紹介します。

マネージドポリシーは再利用性に優れ、ユーザーが必要に応じてロールにアタッチできる、明確に定義され厳密に検証されたポリシーのライブラリを提供します。AWSは利用可能な包括的なポリシーコレクションを提供しており、お客様は独自のマネージドポリシーを作成することも可能です。

これらをそれぞれ詳しく見ていき、いくつかの例とユースケースを確認しましょう。

インラインポリシー

前述の通り、インラインポリシーの使用は例外的なケースに留めるべきです。ポリシーで定義された権限とエンティティの間には厳密な一対一の関係を保つ必要があります。ご想像の通り、インラインポリシーとエンティティの間には緊密な結合関係があります。エンティティを削除すると、そのエンティティに関連付けられたすべてのインラインポリシーも削除されます。権限が複数のエンティティに適用される可能性がある場合は、マネージドポリシーの使用が推奨されます。

インラインポリシーを選択する例としては、誰かが誤ってそれらの権限を別のエンティティに割り当てないようにしたい場合が挙げられます。組織が各部門に S3 フォルダを割り当てているケースを考えてみましょう。組織は、CIO のみが全部門のフォルダへのアクセス権を付与し、アクセス権限を設定できると決定しました。許可されたユーザーに対して、そのユーザープロファイルのみにこの権限を付与するインラインポリシーを作成できます。

新しい CIO ユーザーを作成した後、その AWS ユーザープロファイルに以下のような内容が表示される場合があります。

AWS IAM Inline Policies vs. Managed Policies

インラインポリシーを追加リンクをクリックすると、シンプルなJSONエディターまたは手順を案内するビジュアルエディターを使用してインラインポリシーを追加できるページに移動します。ここではビジュアルエディターを選択し、以下のポリシーを入力しましょう：

  • サービス：S3
  • アクション：すべてのS3アクション (s3:*)
  • リソース：すべてのリソース
  • リクエスト条件：MFA必須

選択後 those options and clicking on the Review policy button, you can review the actions allowed by this policy.

AWS IAM Inline Policies vs. Managed Policies

ポリシーを作成ボタンをクリックすると、このポリシーが当該ユーザーに対してインラインポリシーとして追加されます。なお、CIO_Inline_Policyは他のユーザーアカウントではご利用いただけません。

AWS IAM Inline Policies vs. Managed Policies

このポリシーまたは関連するユーザーを削除すると、ポリシーは存在しなくなります。この例はやや極端ではありますが、インラインポリシーの適用方法を示しています。より穏やかな例としては、AWS Lambda 関数が AWS SQS キューにイベントを送信する場合が挙げられます。この Lambda 関数だけがキューにイベントを送信できるようにしたい場合、Lambda 関数が引き継ぐロールを作成し、そのロールに特定のインラインポリシーをアタッチします。このポリシーでは、SQS キューの ARN に対して sqs:SendMessage アクションを許可します。

マネージドポリシー

マネージドポリシーとは、権限管理を可能な限り容易にするためにAWSが作成・管理するポリシーの集合体です。具体的には、AWSマネージドポリシーを指します。特定のリソースタイプやそのタイプで利用可能なアクションを選択する代わりに、要件を満たすAWSマネージドポリシーを選択し、ユーザー、ユーザーグループ、またはロールにアタッチすることができます。

先ほどの例に戻りますと、例えば「IT管理」ユーザーグループのメンバー全員が、AWSアカウント内のすべてのS3リソースに対して読み取り専用アクセス権を持つとします。ユーザーグループのプロファイルページで、権限を追加ボタンをクリックし、既存のポリシーを直接アタッチを選択します。すると、グループにアタッチ可能なAWSマネージドポリシーの一覧が表示されます。執筆時点では、AWSは807種類のマネージドポリシーから選択可能です。エンティティに関連付けるポリシーは、1つまたは複数選択することが可能です。

AWS IAM Inline Policies vs. Managed Policies

AWSマネージドポリシーをご利用いただく利点は、リソースに対する特定の操作が事前に選択され、厳密に検証されているため、指定された権限のみが付与される点にあります。AmazonS3ReadOnlyAccessポリシーの場合、S3で許可される操作はListおよびGet権限のみとなります。つまり、このポリシーが割り当てられたエンティティは、S3の読み取りのみが可能であり（書き込みはできません）、書き込み操作は行えません。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*",
                "s3-object-lambda:Get*",
                "s3-object-lambda:List*"
            ],
            "Resource": "*"
        }
    ]
}Code language: Perl (perl)

インラインポリシーとは異なり、エンティティとマネージドポリシーの関連付けはアソシエーションによって行われます。エンティティを削除しても、ポリシーはそのまま残ります。

カスタマーマネージドポリシー

AWSは、特定のAWSリソース全体に適用しやすいシンプルな設計としてマネージドポリシーを提供しています。小規模な組織においては、これは理にかなっており、権限管理に伴う管理上の負担を軽減します。しかし、組織が成長するにつれて、複数のユーザー、ユーザーグループ、ロールに適用されるより具体的なポリシーを作成する必要が生じます。カスタマー管理ポリシーは、AWS管理ポリシーと同様の多くの利点を備えつつ、この柔軟性を提供します。

S3バケットにプロジェクトリソースを保存しているプロジェクトを持つ組織を例に考えてみましょう。エンジニア、QAチーム、運用チームにこのバケットへのアクセス権を付与する必要がありますが、アカウント内のすべてのS3リソースへのアクセス権を付与することは避けたいとします。この場合、このバケットへのフルアクセス権を提供するカスタマーマネージドポリシーを作成し、各チームのユーザーグループに関連付けることができます。

IAMコンソールでは、アクセス管理の下にあるポリシーオプションを選択し、ポリシーの作成ボタンをクリックします。インラインポリシーの作成と同様に、ビジュアルエディタを使用するか、JSONエディタでポリシーを入力できます。今回はJSONオプションを使用します。この例におけるバケットのARNはarn:aws:s3:::acme-corp-projects-omega-groupであり、ポリシーにはフルアクセス権を付与します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListStorageLensConfigurations",
                "s3:ListAccessPointsForObjectLambda",
                "s3:GetAccessPoint",
                "s3:PutAccountPublicAccessBlock",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAllMyBuckets",
                "s3:ListAccessPoints",
                "s3:PutAccessPointPublicAccessBlock",
                "s3:ListJobs",
                "s3:PutStorageLensConfiguration",
                "s3:ListMultiRegionAccessPoints",
                "s3:CreateJob"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::acme-corp-projects-omega-group"
        }
    ]
}
Code language: Perl (perl)

このポリシーをOmega_Projectとして保存し、関係する各チームのユーザーグループに関連付けることができます。AWSマネージドポリシーと同様に、このポリシーは関連付けられた各エンティティから独立して存在します。追加のユーザーやグループが同じアクセス権を必要とする場合、このポリシーをそのエンティティに関連付けるだけで済みます。

適切なポリシーの選択方法

適切なポリシーの種類を選択するには、エンティティに付与する必要のある権限の種類と、それらの権限の範囲を考慮する必要があります。場合によっては、インラインポリシーが最も適切かつ論理的な選択肢となることがあります。ただし、AWS マネージドポリシーが要件を満たす場合、またはポリシーが組織内の複数のエンティティに適用される可能性がある場合は、マネージドポリシーが最適な選択肢となります。

ユースケースに適したポリシーを選択する際には、以下のガイドラインをご参照ください：

  • 対象エンティティは特定の種類のすべてのAWSリソースに対する権限を必要としますか？まずAWSが提供するマネージドポリシーを確認し、ユーザーに必要なアクセスレベルに合致するAWSポリシーを関連付けます。
  • 対象エンティティは特定のAWSリソースに対する権限を必要とし、これらの権限が再利用される可能性や複数のエンティティに関連付けられる可能性はありますか？必要な権限をリソースに付与するポリシーを作成し、これらの権限を必要とするユーザー、ユーザーグループ、またはロールに関連付けます。
  • これらの権限を必要とするエンティティはこれだけであり、誤って他のエンティティに権限が付与されるのを防ぐ必要があるでしょうか？ このエンティティのプロファイル内にインラインポリシーを作成することをご検討ください。このエンティティを削除すると、このポリシーも削除されることにご注意ください。

IAMポリシーは慎重かつ入念なアプローチが必要です。具体的なユースケースを考慮し、リソースを保護しつつ、それらのポリシーを維持するために必要な管理オーバーヘッドを制限するポリシーを選択してください。AWSのようなプラットフォームの利点は、組織の成長や進化に合わせて判断を更新できる点にあります。インラインポリシーを作成した後、マネージドポリシーの方が適切であると判断した場合、インラインポリシーをマネージドポリシーに変換する選択肢があります。

追加のリソースについて

AWSプラットフォームには、Identity and Access Management（IAM）を含む各サービスに関する詳細かつ最新のドキュメントが用意されています。マネージドポリシーとインラインポリシーに関するドキュメントは、各ポリシーの詳細や環境管理の追加的なヒント・プロセスを学ぶための優れたリソースです。