【講演メモ】AWS IAM Blackbelt part2

以下の講演メモです。
動画　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
- https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp_request.html

###ベスプラ 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マネジメントコンソールへリダイレクト

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html

コンソールフェデレーションのメリット
• アカウント管理が統合され、リスクが低減する
• 既存のユーザ情報をそのまま利用
• 既存の権限ベースでの管理が可能
• 既存と同様のポリシーの利用が可能
• アカウントロックポリシーや、パスワード管理ポリシー
• 入退社など一元的な管理が可能
• イントラネットからのみアクセス可能なログイン画面

###ユースケース：Amazon Cognitoを用いたモバイルアプリのWebIDフェデレーション
アプリの利用
↓
リダイレクトして認証の実施IDトークンの取得
↓
IDトークンからCognitoトークンの取得
↓
Cognitoトークンを用いてSTSから一時的な認証情報を取得
↓
一時的な認証情報を取得を用いてAWSサービスにアクセス

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_oidc_cognito.html


#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はアプリケーションのモニタリング。