効果的なIAMポリシーを作成するには
ID管理とアクセス管理 (IAM) の概念は、AWSサービスでのセキュリティ対策に非常によく使用されるため、知識を深める価値が十分にあります。IAMは、さまざまな要素で構成されており、初めて理解しようとする人には複雑に思われるかもしれません。この記事では、IAMの仕組みと概念を詳しく説明し、効果的なIAMポリシーを作成する方法をご紹介します。
忘れてはならないのは、IAMは、AWSが提供しているさまざまな他のサービスと同様のサービスであることです。しかし、IAMによって、こうしたサービスを安全に統合できます。
IAMポリシーとは
AWS IAMは、S3リソースへのユーザー・アクセスを安全に管理できるようにするWebサービスです。IAMを使用すると、AWSリソースにアクセス可能なユーザーの管理（認証）、アクセス可能なリソースの管理、アクセス方法の管理（承認）を行えます。
IAMによってリソースを安全に保つには
リソースへのアクセスを管理するには、ルールを設定し、それをIAM ID（ユーザー、ユーザー・グループ、ロール）に関連付けます。ポリシーとはオブジェクトの一種であり、これにより、IDまたはリソースに関連付けるアクセス権限を指定します。大規模なストレージ・システムでは、IAMプリンシパル（ユーザーまたはロール）によって要求が送信されると、そうしたルールが調べられ、効果的に実装されます。また、ポリシー内に定義済みのアクセス権限により、要求の許可または拒否が判断されます。ほとんどのポリシーにJSONファイルが使用されています。
IAMルールによって、アクションの承認方法が確立されます。これは、そうしたアクションの実行方法には左右されません。ポリシーでGetUserアクションが許可されている場合、そのポリシーが適用されているユーザーは、AWSマネジメント・コンソール、AWS CLI、またはAWS APIを介してユーザー情報を取得できます。IAMユーザーの作成時には、コンソール・アクセス、またはプログラムによるアクセスのどちらを許可するかを指定できます。コンソール・アクセスが許可されているIAMユーザーは、ユーザー名とパスワードを使用してログインできます。プログラムによるアクセスが許可されているユーザーは、アクセス・キーを使用してCLIまたはAPIを操作可能です。
IAMポリシーによってSeagate Lyve Cloud Storageを最適化するには
Lyve Cloudは、S3オブジェクト・ストレージの補完的な要素として機能します。Seagate Lyve Cloudにより、長期利用するコールド・ストレージのセキュリティと操作性が向上します。追加したサービスと連携させると、バックアップとリカバリのデータ保護を強化できます。また、IAMポリシーを使用することで、プライベート、パブリック、ハイブリッド、マルチクラウドの環境全体で、Lyve Cloudに保存している個々のオブジェクトのセキュリティ対策とアクセス権限をカスタマイズできます。
IAMポリシーの種類
使用頻度が最も高いものから最も低いものまで、AWSでは次のポリシーを使用できます。各ポリシー・カテゴリの詳細については、次のセクションを確認してください。
IDベースのポリシー
IAM IDを、管理対象のインライン・ポリシー（ユーザー、ユーザーが属するグループ、またはロール）に関連付けることができます。アクセス権限は、IDベースのポリシーを介してIDに付与されます。
リソースベースのポリシー
リソースをインライン・ポリシーに関連付けることができます。最もよく使用されるリソースベースのポリシーは、S3バケットとIAMロールに関連付けられているポリシーです。アクセス権限は、リソースベースのポリシーを介して、ポリシーで定義したプリンシパルに付与されます。プリンシパルは、リソースと同じアカウントにも異なるアカウントにも存在する可能性があります。
アクセス権限数の限度
管理ポリシーを利用して、IAMエンティティ（ユーザーまたはロール）のアクセス権限を定義できます。このポリシーでは、IDベースのポリシーによってエンティティに付与可能な最大アクセス権限数を決定しますが、そうした権限の付与は行いません。アクセス権限数の限度は、リソースベースのポリシーによってオブジェクトに付与できる最大アクセス権限数を指定するものではありません。
組織SCP
AWS Organizationsサービスコントロール・ポリシー (SCP) を利用して、組織または組織単位のアカウント・メンバーが持つことのできる最大アクセス権限数を設定できます。SCPでは、IDベースまたはリソースベースのルールによってアカウント・エンティティ（ユーザーまたはロール）に付与するアクセス権限の数を制限しますが、そうした権限の付与は行いません。
アクセス・コントロール・リスト (ACL)
ACLを使用すると、他のアカウントのプリンシパルによって、リソースへのアクセスを制限できます。ACLは、リソースベースのポリシーに似ていますが、ポリシー形式のなかでは唯一、ポリシー・ドキュメントにJSON構造を使用しません。また、ACLは複数のアカウントにまたがるアクセス権限ルールであり、これによって、指定したプリンシパルにアクセス権限を付与します。ACLでは、同じアカウントのメンバーであるエンティティにはアクセス権限を付与できません。
セッション・ポリシー
AWS CLIまたはAWS APIを使用してロールまたはフェデレーション済みユーザーを受け入れる場合、高度なセッション・ルールを渡すことができます。セッション・ポリシーを使用すると、ロールまたはユーザーIDベースのルールによってセッションに付与するアクセス権限を制限できます。これらのポリシーによって、新しく確立するセッションに関連付けるアクセス権限が定義されますが、そうした権限の付与は行われません。
IAMポリシー構造の重要な要素
IAMユーザー
AWS IAMユーザーは、AWSとやり取りする個人またはアプリケーションを表すために作成するエンティティです。AWSユーザーは、名前と認証情報で構成されます。
管理者権限を持つIAMユーザーは、AWSアカウントのrootユーザーと同義ではありません。AWSアカウントは、一意のIAMユーザーに関連付けられています。
IAM ID
IAMリソースの識別とグループ化を行うために使用するリソース・オブジェクト。IAM IDにはポリシーをアタッチできます。これには、ユーザー、グループ、ロールが含まれます。
IAMリソース
これには、ユーザー、グループ、ロール、ポリシー、IDプロバイダなどのオブジェクトが含まれます。IAMを使用すると、他のAWSサービスと同様に、リソースを追加、編集、削除できます。
IAMエンティティ
AWSでは、認証にIAMリソース・オブジェクトを使用します。これには、IAMのユーザーとロールが含まれます。
プリンシパル
AWSアカウントのrootユーザー、IAMユーザー、またはIAMロールを使用してAWSにサインインするアプリケーションまたはユーザー。これには、フェデレーション済みユーザーと受け入れるロールが含まれます。
職務
AWSでは、ロールはIDオブジェクトであり、そのIDで実行できる操作は権限ポリシーによって決まるため、ユーザーに似ています。ただし、ロールは認証情報（パスワードまたはアクセス・キー）には関連付けられません。個々のロールは、一意のユーザーにのみ関連付けるためではなく、それを必要とする任意のユーザーが受け入れるために使用します。
効果的なIAMポリシーを作成するには
AWSマネジメント・コンソールで次のいずれかの手法を使用して、カスタマー管理ポリシーを作成できます。
- JSON：公開されているIDベースのポリシーの例を貼り付けて変更します。
- ビジュアル・エディタ：ビジュアル・エディタを使用して、新しいポリシーを最初から作成します。ビジュアル・エディタを使用する場合、JSON構文の知識は不要です。
- インポート：アカウント内から、管理ポリシーをインポートして変更します。以前開発したAWS管理ポリシーまたはカスタマー管理ポリシーをインポートできます。
AWSアカウントでは、IAMリソースの数と量に制限があります。詳細については、「IAMとAWS STSクォータ」をご覧ください。
IAM Policy Generator：ポリシー作成プロセスを自動化するには
AWS Policy Generatorは、AWSの製品とリソースへのアクセス管理ルールを開発するツールです。
新しくリリースされたAWS Policy Generatorでは、オブジェクト・ストレージを対象にしたポリシー・ドキュメントの開発プロセスを合理化できます。最初に、作成するポリシーの種類を選択します。
ステップ1：ポリシーの種類の選択
アクセス権限はポリシー内に含まれています。次の種類のポリシーを作成できます。IAMポリシー、S3バケット・ポリシー、SNSトピック・ポリシー、VPCエンドポイント・ポリシー、およびSQSキュー・ポリシー。
ステップ2：ステートメントの追加
ステートメントとは、1つのアクセス権限の概要を示したものです。ステートメントで使用できる項目については、次の説明を確認してください。
ステップ3：ポリシーの生成
ステートメントを追加したら、ポリシーを生成できます。ポリシーとは、1つ以上のステートメントを含む、（アクセス・ポリシー言語で書かれた）ドキュメントを意味します。
