グループを使用してIAMユーザーを適切に管理する

IAMは、AWSリソースへの管理されたアクセスを従業員、AWSサービス、遠隔サーバー上で実行されているプログラムに提供することを可能にします。IAMグループは、複数のユーザーの権限を一度に定義できる便利な組織ツールです。

IAMの組織ツール

まず最初に、IAMのさまざまなツールについて簡単に説明します:

IAMポリシーは、個々の権限をまとめて、一貫したオブジェクトを形成し、ユーザー、ロール、グループに適用できます。たとえば、特定のS3バケットのセットにオブジェクトを追加することを許可するポリシーを作成できます。

IAMユーザーは、CLI、API、または管理コンソールからAWSサービスにアクセスするためのアクセスキーやパスワードを持っています。これにより、従業員はAWSアカウントの外部からAWSリソースにアクセスできるようになります。彼らは自分のアカウントにポリシーが添付されており、これが許可を与えます。

IAMロールはユーザーに似ていますが、アクセスキーは付属していません。これらは、他のAWSサービスにあなたのリソースを使用する権限を与えるために使用され、あなたのアカウントの外にいる誰にもAPIまたはCLIアクセスを提供しません。例えば、EC2インスタンスにS3にアクセスすることを許可するロールを与えることができ、すでにあなたのAWSアカウント内で実行されているため、アクセスキーを必要とせずにそのロールとして機能できます。

AWS Organizationsは、ルートAWSアカウントを最大4つの異なるサブアカウントに分割し、中央管理の請求と制御を可能にする特別なツールです。技術的にはIAMとは無関係ですが、これにより開発、テスト、ステージング、プロダクション環境を完全に分離することが可能になり、開発環境でのみ作業する従業員に対してより緩いIAM権限を与えることができます。

今日私たちが話し合うのはIAMグループです。このツールを使用すると、グループに複数のポリシーを関連付け、ユーザーをそのグループに追加することができます。追加されたユーザーは、グループが持っているのと同じポリシーが付与されます。これは優れた組織ツールであり、複数のユーザーを管理するために重要です。

グループで働く方法

グループを使用すると、異なる権限を持つ異なるクラスの従業員を区別することができます。例えば、ソフトウェア開発者のチームとQAエンジニアのチームがあるとしましょう。どちらのチームも異なる要件があり、そのため異なる権限が必要です。グループで設定することで、新しい従業員にアクセス権を簡単に設定したり、必要に応じてユーザーをチーム間で移動させたりすることができます。

IAM管理コンソールの「グループ」タブから新しいグループを作成します。

名前を付けて、任意のポリシーを添付してください。グループには最大10個のポリシーを添付できますので、このグループ用にカスタムポリシーを1つか2つ作成することをお勧めします。また、グループにインラインポリシーを直接追加することもできますが、すべてを整然と保つために通常のポリシーを使用することをお勧めします。

「作成」をクリックすれば、それだけで設定は完了です。グループの「ユーザー」タブからグループに新しいユーザーを追加することができます:

または、オンボーディングプロセスを自動化している場合は、次のようにコマンドラインから実行できます:

aws iam add-user-to-group --group-name <value> --user-name <value>

これにより、グループの権限がユーザーの現在の権限に別のカテゴリとして追加されます。ユーザーをグループから削除すると、グループの権限はもはや適用されなくなります。

サブグループを作成することはできませんが、ユーザーは同時に複数のグループに含めることができます。これを考慮に入れると、基本的な権限を与える「開発者」グループと、より多くの権限を与える「シニア開発者」グループを作成し、両方を従業員に割り当てて両方の権限を与えることができます。

グループは権限を上書きしません

IAMでは、権限が他の権限を「上書き」する方法はありません。デフォルトでは、すべてが暗黙的に拒否され、ユーザーは権限ポリシーによって明示的に許可されたサービスにのみアクセスできます。また、ユーザーに対して権限を明示的に拒否することも選択できます。これらの権限は、ユーザーまたはグループから来るかどうかにかかわらず、他の権限よりも常に優先されます。

グループを作成すると、すべてのグループの権限はユーザーの権限と同じように相互作用します。これは、権限が直接ユーザーに付与されている場合と同じです。階層はありません。

例えば、テストユーザーを作成し、AWSDenyAllポリシーを直接それに適用します。また、グループを作成し、そのグループにAdministratorAccess権限を付与し、そのユーザーをそのグループに追加します。

IAMポリシーシミュレーターからは、AWSDenyAllポリシーの存在によってすべてが明示的に拒否されていることがわかります。もし状況を逆にして、拒否ポリシーをグループに、許可ポリシーをユーザーに直接設定しても、同じことが起こります。拒否は常に許可を上書きします。

これのより便利な形は、権限の境界です。ユーザーができないことを明示的に拒否するのではなく、グループが許可している場合でも、代わりに権限の境界としてポリシーを設定できます。これにより、グループや直接の権限に関係なく、ユーザーに付与されたすべての権限よりも優先され、権限の境界が許可していないことは何も許可されません。

これは基本的に許可のベン図のように機能し、添付されたポリシーの明示的に許可された権限と権限境界の両方が重なるアクションのみを許可します。