この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、菊池です。
2016年9月21日（水）のAWS Black Belt Online Seminarを受講しましたので、レポートします。
今回はAWSを利用する上で必須と言える、Identity and Access Management (IAM)についてです。
AWS Black Belt Online Seminar AWS Identity and Access Management (AWS IAM) from Amazon Web Services Japan
Identity and Access Management (IAM)とは
IAMの概要
AWSをセキュアに利用するための認証・認可の仕組みです。
AWSのユーザ単位
- rootユーザー：AWSのアカウント作成時のIDで、全てのサービス・リソースに対し完全なアクセス権を持ちます。root権限が必要な操作を除いて、日常タスクでは使用しないことが強く推奨されます。
- IAMユーザー：AWS操作用のユーザー。10までのグループに所属可能で、個別にアクセス権限を設定できます。
- IAMグループ：IAMユーザーをまとめるグループ。グループ単位でアクセス権限の付与が可能です。
IAMによる認証
認証情報
アクセスキーID/シークレットアクセスキー：
- REST/Query形式のAPI利用時に使用します。1ユーザにつき2つまで生成可能です。
- 保持の方法に注意
- BAD：GitHUB、AMI埋め込み、文書/メールに記述、コード内に記述
- GOOD：AWS認証情報ファイル、環境変数
X.509認証：
- 証明書を作りアップロードし、SOAP形式のAPIリクエスト時に使用します。
マネジメントコンソールへのログインパスワード：
- デフォルトでは作成されませんので、マネジメントコンソールを利用するユーザーに発行します。
- パスワードポリシーが設定可能です。
- 最小文字数、英大文字、英小文字、数字、記号の要求
- 有効期限や再利用制限など
MFA（多要素認証）：
- ハードウェアMFA（Tokenタイプ。現在カードタイプは利用不可。）
- 仮想MFA
- SMS（プレビュー）
認証情報のローテーション
定期的なローテーションが推奨されます。
- IAM認証情報レポートで認証情報の利用状況を確認可能
- IAMユーザはパスワードポリシーで強制することが可能
- アクセスキーのローテーション
- 新しいアクセスキーを発行しテスト
- 古いキーをInactiveにする（問題があったら再度Activeにすることが可能）
- 古いキーを削除
IAMによる権限設定
IAMポリシー
管理ポリシー ：
2015年に追加。複数のグループ、ユーザー、ロールにアタッチ可能で、5世代まで変更管理も可能。AWSで管理されるAWS管理ポリシーと自由に作成できるカスタマー管理ポリシーがあります。
AWS管理ポリシーでは、AWSのアップデートに伴い追加される機能に対し自動でメンテナンスされます。カスタマー管理ポリシーは権限設定が自由に可能になりますので、用意されたAWS管理ポリシーで要件を満たせない場合に使います。
インラインポリシー：
従来からあるポリシーで、グループ、ユーザー、ロールに直接埋め込まれるポリシーです。複数のユーザーの権限を一括変更などはできませんので、通常は管理ポリシーを使う方がメリットが大きいと思います。
アクセス条件の記述
JSONで記述します。
- Action：操作自体の設定
- Resource：操作対象の設定
- Condition：このアクセス制御を有効/無効の条件設定
アクセス可否の決定ロジック
デフォルトDeny < Allow < 明示的Deny で評価されます。複数の条件に該当した場合、1つでもDenyがあれば拒否されます。
連携するAWSサービス
サービスによってコントロールできる権限レベルが異なります。
IAMで設定されるユーザベースのアクセス制御と、S3、SQSなどのサービスによって付与するリソースベースのアクセス制御があります。リソースベースの制御はクロスアカウント間のアクセス許可などに適用します。
ポリシー作成支援ツール
- AWS Policy Generator
- ポリシー言語の文法チェック機能
- IAM Policy Validator
- IAM Policy Simulator
IAMによる監査
- Cloud Trailによるアクティビティの記録：APIコールが記録されるので、適切な利用状態かを確認
- Access AdvisorとService Last Accessed Data：最後にアクセスした記録し、最小権限の維持に利用
- IAM認証情報レポート：最後に利用した日付や変更日の記録
- AWS ConfigのIAMサポート：変更管理
AWS Security Token ServiceとIAMロール
IAMロールとは
AWSサービスやアプリケーション等のエンティティに権限を付与する仕組みで、IAMユーザ/グループとは紐付かない別の管理になります。ロールに対しIAMポリシーをアタッチして権限を管理します。
EC2にはIAMロールを利用することで、認証情報をOSやアプリケーションに持たせる必要がなく、認証情報漏洩のリスクを低減できます。
IAMロールを設定したEC2では、有効期限つきのセッショントークンを取得することで認証されます。
Security Token Serviceとは
一時的に利用するトークンを発行するサービス。期限付きの一時認証情報を発行します。
IAMの権限階層
ユースケース
- IAMロールによるクロスアカウントアクセス
- AWSアカウント間のアクセスにMFA保護も可能
- Switch Roleで複数アカウントのマネジメントコンソールを切替が可能
IAMによるFederation
ID連携
- 組織・企業の認証機能と連携が可能
- OpenID ConnectとSAML2.0をサポートしています。
ユースケース
- SAML2.0によるSSO Federation
- Console Federation：マネジメントコンソールへの既存のIDプロバイダを使ったシングルサインオン
- Web ID Federaiotn：モバイルアプリから認証サーバ不要でアクセス
認証連携を使うことで、組織内でのアカウント管理が統合されリスク低減し、よりセキュアな運用ができます。
まとめ
- IAMのベストプラクティスを併せて参照
- IAMを利用することでセキュアなAWSの利用が可能
- STSをうまく使うことで、AWSサービスをアプリケーションやモバイルから直接利用できる
- IAM自体に利用料は発生しないので積極的な利用を！！
今後のオンラインセミナー
最後に
IAMはAWSを使う上でほぼ必須と言える重要な機能で、使われている方も多いと思います。一方できめ細やかなアクセス制御が可能であり、IAMロール/STSやフェデレーションといった奥の深いサービスでもあります。
うまく使いこなすことで、AWSをセキュアに利用しつつ、オペレーション負荷も低減することができます。
今回このセミナーを受講することで、改めてその機能を体系的に整理することができました。
14
