以下の講演メモです。
動画 https://www.youtube.com/watch?v=qrZKKF6V6Dc
資料 https://d1.awsstatic.com/webinars/jp/pdf/services/20190130_AWS-BlackBelt_IAM_Part2.pdf
IAM概要
IAMロール
- AWSリソースの操作権限を付与するための仕組み
- 認証方法
- 一時的なセキュリティ認証情報を利用
- 複数のユーザーがロールを引き受け(assume)可能
- 別のAWSアカウントのIAMユーザーロール等
- Amazon EC2, AWS Lambda等のAWSサービス
- SAML2.0またはOpenID connectと互換性があるIDプロバイダーによって認証された外部ユーザー
一時的なセキュリティ認証情報
- 有効期限付きで以下で構成
- アクセスキーID
- シークレットアクセスキー
- セキュリティトークン
- ユーザーのリクエストによってSTSが動的に作成
Security Token Service(STS)
- 一時的なセキュリティ認証情報を生成する
- 認証上の期限変更は不可
- 全リージョンで使用可能
- 各リージョンのSTSでアクティベート可能
一時的なセキュリティ認証情報を取得するためのAPI
ベスプラ Amazon EC2インスタンスで実行するアプリケーションに対してIAMロールを使用する。
- 認証情報をEC2(OS/アプリ)側に持たせる必要がない、認証情報の漏洩リスクを低減可能
- IAMロールによる認証情報はAWSが自動的にローテーション
権限の委任
ロールを使用したアクセス許可の委任
ユースケース IAMロールによるクロスアカウントアクセス
あるアカウントのユーザーに別のアカウントのIAMロールに紐付ける機能
例. 開発アカウントで本番環境のS3データを更新するようなケースで利用
開発アカウントにIAMユーザー DevAccouuntロールの権限でアクセス
本番アカウントにS3ForDevAccountロールを用意しておく。
Principalで開発アカウントのARNを書いておく。
○IAM
権限をSTSに要求したときにだれが許可してくれるんだ？STSがどういった理屈で許可するのか不明。
→IAMロールを準備しておくのか。
ユースケース クロスアカウントアクセスにより権限管理を効率化
Jumpカウントを設定して、本番アカウントや開発アカウントのサービスを利用するようにする。
○Switch Role
マネジメントコンソールにアクセスするときに、IAMユーザーからクロスアカウントアクセス用IAMロールに切り替え可能
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_use_switch-role-console.html
SAML2.0ベースのIDフェデレーション
IDPに認証情報にリクエスト
↓
AD認証
↓
認証応答の受け取り
↓
STSにAssumeRoleWithSAMLの呼び出し
↓
一時的な認証情報の受け取り
↓
一時的な認証情報を用いたAPIの呼び出し
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_saml.html
SAML2.0ベースのAWSマネジメントコンソールへのSSO
IDPに認証情報にリクエスト
↓
AD認証
↓
認証応答の受け取り
↓
AWS SSOエンドポイントに対してSAMLアサーションをポスト
↓
SSO エンドポイントが一時的な認証情報をリクエストしサインインURLを生成
↓
サインインURLをクライアントにリダイレクトとして送信
↓
ブラウザがAWSマネジメントコンソールへリダイレクト
コンソールフェデレーションのメリット
• アカウント管理が統合され、リスクが低減する
• 既存のユーザ情報をそのまま利用
• 既存の権限ベースでの管理が可能
• 既存と同様のポリシーの利用が可能
• アカウントロックポリシーや、パスワード管理ポリシー
• 入退社など一元的な管理が可能
• イントラネットからのみアクセス可能なログイン画面
ユースケース：Amazon Cognitoを用いたモバイルアプリのWebIDフェデレーション
アプリの利用
↓
リダイレクトして認証の実施IDトークンの取得
↓
IDトークンからCognitoトークンの取得
↓
Cognitoトークンを用いてSTSから一時的な認証情報を取得
↓
一時的な認証情報を取得を用いてAWSサービスにアクセス
IDと権限のライフサイクル管理
AWSアカウントのアクティビティの監視
AWS CloudTrailは全リージョンでの有効化を推奨。
AWSのロギング機能を有効にしてユーザーがアカウントで実行したアクションや使用されたリソースを
確認する。ログファイルにはアクションの日時、ソースIP、不適切なアクションなどが示される。
CloudTrail
適切なユーザーが与えられた権限で環境を操作しているかの確認と記録に利用。
記録される情報には以下のようなものが含まれる
• APIを呼び出した身元（Who）
• APIを呼び出した時間（When）
• API呼び出し元のSource IP（Where）
• 呼び出されたAPI（What）
• APIの対象となるAWSリソース（What）
• 管理コンソールへのログインの成功・失敗
アクセスレベルを使用して確認する。
アクセスレベルとは
- リスト
- 読み込み
- 書き込み
- アクセス権限の管理
ベスプラ アクセスレベルを使用して確認する。
AWSアカウントのセキュリティを向上させるためにIAMポリシーを定期的に確認し、モニタリングする。
アクセス権限として最小になっているかを確認する。
不要な認証情報を削除する
IAM認証情報レポート
- ユーザーの作成日時
• 最後にパスワードが使われた日時
• 最後にパスワードが変更された日時
• MFAを利用しているか
• Access KeyがActiveか
ベスプラ 不要な認証情報を削除
- パスワードやアクセスキーのローテーションなど、認証情報ライフサイクルの要件結果を監査する
- 社員の入社、部署異動など人員のライフサイクルと連動
- 認証情報レポートを活用する
アクセスアドバイザー
IAMエンティティが最後にAWSサービスにアクセスした日付と時刻を表示する機能。
この人には「最小限の機能」はこれだよ！とアドバイスしてくれるような機能。
認証情報を定期的にローテーションする
認証情報を定期的にローテーション
- IAMユーザーのパスワード、アクセスキー、シークレットアクセスキーを定期的にローテーションする
- パスワードローテーション
- パスワードに有効期限を設定して利用者が自分でパスワードローテーションできるようにする
- アクセスキーのローテーション
- アクセスキーは2つまで作成可能
- 新しい認証情報でテストをして古いアクセスキーは無効化しておく。
- 問題が起きたら古いアクセスキーを再び有効化する。
学んだこと・疑問点
権限をSTSに要求したときにだれが許可してくれるんだ？STSがどういった理屈で許可するのか不明。
→→IAMロールを準備しておく。許可されるようにアイデンティティベースのポリシーで書いておく。
CloudWatchはアプリケーションのモニタリング。