責任分担セキュリティモデル
利用者 とAWS が協力してセキュリティを高める考え方
・不正アクセスの保護など
システムのどの階層について責任を分担するかは利用するAWSサービスによって異なる
アブストラクトサービス > コンテナサービス > インフラストラクチャサービス
の順でAWSの責任範囲 が多い
インフラストラクチャサービス（例：EC2）
利用者の責任範囲
・データ
・アプリ
・OS
・ネットワーク
・ファイアウォール
・データ・通信の暗号化
・AWSアカウント
・IAMユーザ
AWSの責任範囲
・インフラストラクチャ（物理ホスト/ストレージ/ネットワーク）
・AWSデータセンタ（リージョン/AZ/エッジロケーション）
コンテナサービス（例：RDS）
利用者の責任範囲
・データ
・アプリ
・暗号化
・プラットフォーム/アプリケーション管理
・ファイアウォール
・AWSアカウント
・IAMユーザ
AWSの責任範囲
・OS
・ネットワーク
・インフラストラクチャ（物理ホスト/ストレージ/ネットワーク）
・AWSデータセンタ（リージョン/AZ/エッジロケーション）
アブストラクトサービス（例：S3）
利用者の責任範囲
・データ
・クライアントサイド暗号化
・AWSアカウント
・IAMユーザ
AWSの責任範囲
・ネットワーク/サーバーサイド暗号化
・プラットフォーム/アプリケーション管理
・OS
・ネットワーク
・インフラストラクチャ（物理ホスト/ストレージ/ネットワーク）
・AWSデータセンタ（リージョン/AZ/エッジロケーション）
注意点
侵入テストなどセキュリティ対策後のテストを行う場合は、AWSに事前申請が必要！
申請なしで実施すると 利用規約違反 となるので注意
ルートアカウント
アカウント作成時のアカウント
全ての操作が可能
権限の制御はできない
操作ミス、パスワード漏洩などのセキュリティ観点から、ルートアカウントは使用しない ことが望ましい。
AWSの操作は、アカウント内に別ユーザーを作成してそのユーザーで行う。
1アカウント内にユーザーは複数作成が可能。
IAM（Identity and Access Management）
AWSの各種サービスを利用する上での認証とアクセス制御を提供するサービス
IAMで、ユーザー（IAMユーザー）やグループ（IAMグループ）を作成。
ユーザー、グループ毎にアクセス制御を設定（IAMポリシー）する。
（各種リソースにアクセス権限を付与する IAMロール というものもある）
IAMポリシーは、最小権限のアクセス権を与えることが望ましい。
＊ アクセスの許可と拒否、両方が設定されている場合は、拒否のポリシーが優先 される
AWSサービスの操作方法と認証情報
| 操作方法 | 認証情報 | |
|---|---|---|
| Webブラウザ | マネージメントコントロール | ユーザー名 / パスワード |
| コマンド | AWS CLI | アクセスキー / シークレットキー |
| プログラム | AWS SDK | アクセスキー / シークレットキー |
＊ プログラムでの認証情報の利用は非推奨！
→ 認証情報の更新、パスワードの流出の危険性があるため。
IAMロールを割り当てることが望ましい
例） EC2インスタンスにIAMロールを割り当てると、アクセスキー/シークレットキーがなくてもアクセス可能になる
IDフェデレーション
使用シーン
・複数の使用頻度が少ないユーザーに対して、IAMユーザーを登録をするのが手間。回避策としてIDフェデレーションを使用する
用語
STS（Security Token Service）
一時的に認証情報を付与するサービス
IDブローカー（IDプロバイダー）
認証用サーバーのイメージ
認証基盤は、ユーザーが独自で用意
シングルサインインなどにも対応しているのでそちらを使うのもOK
（Google、Facebook、SAMLなど）
仕組み
IDフェデーションを使用して、S3に一時的にアクセスする方法
- ユーザーが社内に立てたIDブローカー（認証サーバー）にアクセス
- ユーザーID/パスワードなどを入力してログイン
- IDブローカー（認証サーバー）がSTSから、一時的に認証情報を取得する
- STSから取得した認証情報を使ってS3にアクセス（アップロードなど）