AWS再入門2018 Identity and Access Management（IAM）編

成人の日を迎えた皆様おめでとうございます。自分の成人式は何年前だったか、考えないことにした池田です。

はじめに

今回はAWS各種サービスを利用していく上で重要な要素の１つであるIdentity and Access Management（IAM）について整理していきます。 前回に続いてAWS再入門2018と題して勝手にシリーズ化させていこうとしていますので、お付き合いいただけますと幸いです。

参考とした資料は2017年12月に「Identity and Access Management: The First Step in AWS Security」というタイトルで公開されたこちらのスライドになります。

もくじ

• IAMとは
• AWSにおけるIAM
• IAMユーザーとグループ
• IAMの認証と認可（Authentication & Authorization）
• IAMポリシーとは
• IAMの評価ロジック
• Privilege Escalation（特権エスカレーション）の防止
• AWS Identity Federation
• AWS Organizations & Service Control Policies
• IAMベストプラクティス
• まとめ

IAMとは

• IAMは予防的なセキュリティ制御
• セキュリティ管理とは何か
• ITリソースへのアクセスを管理するためのハードウェア、ソフトウェア、ポリシー、または手順
• 予防的セキュリティ制御とは、望ましくない活動や不正な活動を阻​​止するもの

AWSにおけるIAM

• AWSユーザーとグループを作成および管理することで、AWSリソースへのアクセスを許可および拒否する
• Security Assertion Markup Language（SAML）IDフェデレーションとAWSディレクトリサービスを使用してMicrosoft Active Directoryと統合が可能
• ロールを作成して、エンティティまたはAWSサービス（EC2インスタンスなど）が実行できる操作を制御する
• ユーザーまたはロールに権限を指定することで、AWSリソースで実行できる操作を制御する
• IAMサービスは、AWSマネジメントコンソール、AWS API、およびAWSコマンドラインインターフェイス（CLI）へのアクセスを提供（OSやアプリケーションの認証は提供しない）

IAMユーザーとグループ

IAMユーザーとは

• AWSサービスへのアクセスを必要とする個人、システム、またはアプリケーションを指す
• ユーザーアカウントは、パスワード、アクセスキー、マルチファクタ認証（MFA）などの一意の名前とセキュリティ資格情報で構成される
• AWSマネジメントコンソールにアクセスするときにパスワードが必要

IAMグループとは

• 組織の論理ユニットおよび機能ユニットをグループとしてそれぞれに権限を割り当てる方法
• 業務の効率化を支援するツール（複数ユーザーをグループ化することでユーザーごとに設定する手間を省略できるなど）
• アクセス権の一括管理（スケーラブル）
• ユーザーの異動などに伴う権限の変更や、ユーザーの入れ替えも簡単に行える（ポータブル）

IAMロールとは

• IAMユーザーと同様にAWSのIDであり、各種操作の実行許可を与えるまたは与えないということを決定するポリシーのこと
• IAMロールの対象
• 個人
• Amazon EC2インスタンス
• カスタムコード
• その他のAWSサービス

IAMの認証と認可（Authentication & Authorization）

IAMアクセスキーとは

• プログラムによるAWSへの呼び出しを行うために使用される
• AWSコマンドラインインターフェイス（CLI）
• AWS SDK
• 個々のAWSサービスAPIをHTTPS通信で直接呼び出す
• アクセスキーIDとシークレットアクセスキーで構成
• アクセスキーID例：AKIA3R7HGUSSI4BOW
• シークレットアクセスキー例：MxQ4QSzT0NsnEO5VNCYjJo

署名手続き（signing process）とは

• AWS Signature Version 4は各種AWSリクエストに認証情報を追加するプロセス
• AWS SDKまたはCLIツールは、ユーザーが提供するアクセスキーを使用して、リクエストを作成、署名、送信を行う
• AWS APIリクエストを自分で作成する場合は、リクエストに署名するコードを含める必要がある
• http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

IAMパスワードとは

• IAMユーザーがAWSマネジメントコンソールへアクセスする際の認証に使用される
• パスワードポリシーを設定することができる
• 英数字と一般的な特殊文字が使用可能
• ！ @＃$％^＆*（）_ + - = [] {} | '

アクセスキーとパスワードの使い分け

• ユーザーがAWSにアクセスする方法に依存
• コンソールならパスワード
• API、CLI、SDKならアクセスキー
• 定期的なローテーションを行うことでリスクを低減
• 資格情報レポート（Credential Report）による資格情報のローテーションを監査
• パスワードポリシーで単純なパスワードを禁止するよう設定
• アクセスキーのローテーションを許可するポリシーの設定

IAMプリンシパルとは

• IAMプリンシパル
• ユーザー、アカウント、サービス、役割、またはその他のエンティティ
• リソースへのアクセスが許可または拒否されるエンティティとして定義 > プリンシパル（依頼者）: シークレットアクセスキーに基づいて識別されます。この情報は、ルートユーザー、IAM ユーザー、フェデレーティッドユーザー (STS 経由)、または引き受けられたロールを表す場合があり、そのプリンシパルに関連付けられた権限の集合を含みます。 IAM JSON ポリシーの評価論理

IAMポリシーとは

アイデンティティベース（IDベース）のポリシーとリソースベースのポリシーにわかれる

アイデンティティベース（IDベース）のポリシー

• アクセス制御とアクセス権を定義するJSONベースのステートメント
• インラインポリシーと管理ポリシーにわかれる

インラインポリシー

• 単一のユーザー、グループ、またはロールに直接埋め込まれたポリシー

管理ポリシー

• IAMユーザー、グループ、またはそれらが接続されているロールとは別に管理できるスタンドアロンポリシー
• AWS管理ポリシーとカスタマー管理ポリシーがある >・ AWS 管理ポリシー – AWS が作成および管理する管理ポリシー。ポリシーを初めて利用する場合は、AWS 管理ポリシーから開始することをお勧めします。 ・カスタマー管理ポリシー – AWS アカウントで作成および管理する管理ポリシー。カスタマー管理ポリシーでは、AWS 管理ポリシーに比べて、より正確にポリシーを管理できます。ビジュアルエディタで IAM ポリシーを作成および編集することも、JSON ポリシードキュメントを直接作成することもできます。詳細については、「IAM ポリシーの作成」および「IAM ポリシーを編集する」を参照してください。 ・インラインポリシー – 自身で作成および管理するポリシーで、単一のユーザー、グループ、またはロールに直接埋め込まれています。 IAM ポリシー

インラインポリシーが適した場面

• ポリシーとプリンシパルの間に厳密な1対1の関係を強制する場面
• プリンシパルに間違ったポリシーが付かないようにする
• プリンシパルを削除するときにポリシーが削除されていることを確認する

管理ポリシーが適した場面

• 繰り返し同じポリシーを利用したい場合
• ポリシーの一括管理、一括変更をしたい場合
• バージョン管理とロールバックをしたい場合
• 権限管理の委任
• AWS管理ポリシーの自動更新
• ポリシーサイズの拡大

リソースベースのポリシー

• サポートされるリソースにインラインポリシーをアタッチする
• Amazon SNSトピック、Amazon S3バケット、AWS KMSキー、Amazon Glacier Vaultなど
• プリンシパルと呼ばれるリソースにアクセスできるユーザーを指定する必要がある

ポリシーとプリンシパル

• アイデンティティベース（IDベース）のポリシーでは、プリンシパルは暗黙的
• リソースベースのポリシーでは、プリンシパルは明示的

IAMの評価ロジック

• 決定がDenyから開始される
• AWSは、ユーザーとリソースに関連付けられたすべてのポリシーを取得
• アクションと条件に一致するポリシーのみが評価される
• 該当するすべてのポリシーを評価する
• 明示的な拒否があるか
• ある場合、応答は「拒否」となる
• ない場合、次へ進む
• 許可があるか
• ある場合、応答は「許可」となる
• 許可されるのは明示的な許可があり、拒否がない場合
• ない場合、次へ進む
• 応答は「拒否」となる
• デフォルトでの応答は「暗黙の拒否」となる

このロジックについては、公式ドキュメントIAM JSON ポリシーの評価論理 にて、例を挙げて解説されています。

Privilege Escalation（特権エスカレーション）の防止

• 完全なIAM権限を持つプリンシパルは、他の権限が付与されていない場合でも、実質的にスーパーユーザーである
• プリンシパルは、いつでも独自のアクセス許可を変更できる
• これを防ぐには、少なくとも次のIAMアクションへのアクセスを拒否する
• iam：AttachUserPolicy
• iam：AttachGroupPolicy
• iam：AttachRolePolicy
• iam：PutUserPolicy
• iam：PutGroupPolicy
• iam：PutRolePolicy
• 特権エスカレーションの具体例は"混乱した代理" 問題として解説されています。

IAM Policy Simulatorとは

• アカウントのリソースに対してポリシーをテストできるツール
• AWSアカウントのIAMユーザー、グループ、またはロールに添付されているポリシーをテストする
•  Amazon S3バケット、Amazon SQSキュー、Amazon SNSトピック、Amazon Glacier VaultなどのAWSリソースに添付されたテストポリシー
• 新規に作成するなどし、ユーザー、グループ、またはロールにアタッチしていないポリシーをシミュレータに入力またはコピーして利用する
• 選択したサービス、アクション、およびリソースを使用してポリシーをテスト
• テスト対象のポリシーのCondition要素に含まれるコンテキストキー（IPアドレスや日付など）を提供することで、実際のシナリオをシミュレート
• 特定のリソースまたはアクションへのアクセス許可または拒否をするポリシーのステートメントを識別する

IAM Policy Generatorとは

AWS IAM Consoleには、IAMポリシーの構築に役立つ簡単なGUIツールが用意されている 参考： ビジュアルエディタを使用してポリシーを作成する

AWS Identity Federation

一般的なシナリオ

• ほとんどの組織は、社内ディレクトリ（IAMロールを介したフェデレーションユーザー）を使用してIAMと統合する
• IAMロールは一般的に、EC2インスタンス上で実行されているアプリケーションに対して、AWSサービスへの詳細な権限を指定するためにも使用される
• IAMユーザーは、通常、「ブレークグラス」シナリオでAWSリソースへのアクセスを提供するために使用される
• IAM管理ポリシーは、1か所で更新して複数のエンティティに適用できるため、インラインポリシーよりも優先する必要がある

IAMユーザーとフェデレーションユーザー

• IAMは、AWSのID管理システムで管理されるユーザーをサポートする
• AWS外の企業ディレクトリで管理されているユーザーを「フェデレーションユーザー」と呼ぶ
• 企業ディレクトリの例： Microsoft Active Directory、PingFederate、Okta Univeral Directoryなど

IAM Identityプロバイダ

• AWSアカウントでIAMユーザーを作成する代わりに、AWS以外で管理されているアイデンティティを使用できる仕組み
• カスタムサインインコードを作成したり、独自のIDを管理する必要はない
• Microsoft Active Directoryなどの社内ユーザーディレクトリのような独自のIDシステムがある場合に役立つ

SAML 2.0-based Federation

• SAML 2.0は、多くのアイデンティティプロバイダ（IdP）が使用するオープンスタンダード
• SSO（Single Sign-On）が可能になるため、組織の全員向けにIAMユーザーを作成することなく、AWS管理コンソールにログインしたり、AWS APIを呼び出すことができる 参考： SAML 2.0 ベースのフェデレーションについて

AWSセキュリティトークンサービス（STS）

AWS IDおよびアクセス管理（IAM）ユーザーまたは認証したユーザー（フェデレーションユーザー）のための一時的、限定的な権限のクレデンシャルを要求できるWebサービス

IDとフェデレーションについて

• IAMユーザーは、AWS APIを呼び出すためにパスワードまたはアクセスキーが必要か？
• アクセスキーが必要。パスワードは、AWS管理コンソールにログインするためにのみ使用される
• EC2インスタンス上で実行されているコードがDynamoDBにアクセスする場合は、アクセスキーまたはIAMロールを使用する必要があるか？
• IAMロールを使用する方が、アクセスキーよりも管理がしやすい
• "iam：CreatePolicy"と "iam：AttachRolePolicy"どちらの権限が強いか
• "iam：AttachRolePolicy"：ロールにポリシーを付加して権限をエスカレートすることができるため

AWS Organizations & Service Control Policies

AWS Organizations

• 複数のAWSアカウント間でポリシーを集中管理できる
• 既存のアカウントを組織に結合して、自動的に組織の一部であるアカウントを作成し、他のアカウントを組織に招待することができる。アカウントを組織単位 (OU) にグループ化することができる
• サービス制御ポリシー（SCP）と呼ばれるポリシーベースのコントロールをアタッチして、複数のAWSアカウント間でのAWSサービスの使用を集中管理する
• 統合請求による単一の支払い方法を可能にすることにより、複数のアカウントの請求を簡素化

この機能については公式ドキュメントAWS Organizations 機能にて詳しく解説されています。

AWS Organizations Policies

• 1つ以上のステートメントでAWSアカウントのグループに適用するコントロールを定義
• サービス制御ポリシー（SCP:Service Control Policy）を提供している
• Amazon EC2など、組織内のさまざまなアカウントで使用できるAWSサービスとアクションを制限
• プリンシパル（アカウントルート、IAMユーザー、およびIAMロール）からアクセス可能なAWSサービスとアクションを制御
• SCPがアタッチされているアカウントのプリンシパルに対する認可は、SCPで明示的に許可されているものと、プリンシパルにアタッチされているIAMのアクセス許可で明示的に許可されているものの共通部分

IAMベストプラクティス

• AWSアカウント（ルート）アクセスキーをロック解除する
• 個々のIAMユーザーを作成する
• グループを使用してIAMユーザーに権限を割り当てる
• 最小限の権限を与える
• ユーザーに強力なパスワードポリシーを設定する
• 特権ユーザーに対してMFAを有効にする
• Amazon EC2インスタンス上で実行されるアプリケーションにはロールを使用する
• 資格情報を共有する代わりにロールを使用して委任する
• 定期的に資格情報をローテーションする
• 不要な資格情報を削除する
• セキュリティを強化するためにポリシー条件を使用する
• AWSアカウントのアクティビティを監視する
• http://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

まとめ

改めてIAMについて振り返ってみました。セキュリティリスクを低減するためにも1つひとつの機能とその意味を理解し、適切な設定を行う必要があることがわかりました。 AWSに限らず、既に多方面で言われているセキュリティの基本的なことも多く含まれていました。慣れや勘違い、見落としなどが無いか、定期的に確認を行っていくのは重要ですね。