ポリシー（パーミッション）
・ユーザ・グループにはJSONで書かれるポリシーを割り当てることができる
構成要素
{ ”Version“: “2012-10-17”, # ポリシー記述言語のバージョン。常にこれ。
”Id“: “任意の識別子”, # オプション
”Statement“: [ # １つ以上の宣言が必須
{
”Sid“: “任意の識別子”, # オプション
”Effect“: “Allow”, # 許可Allow / 拒否Deny
”Principal“: { # このポリシーが適用されるアカウント/ユーザ/ロール
”AWS”: [“arn:aws:iam::123456789012:root”]
},
”Action“: [ # このポリシーで許可/拒否されるアクションの一覧
”s3:GetObject”,
”s3:PutObject”
],
”Resource“: [“arn:aws:s3:::mybucket/*”] # アクションの対象となるリソースの一覧
}
]
}
・ポリシーは、ユーザの権限を定義するもの
・最小権限の法則：必要な最小限の権限を割り当てるようにする
・rootユーザは使わず、管理用ユーザを作って操作するのがベストプラクティス
※Chromeの新規シークレットウインドウを開くと、ログイン中のユーザと別のユーザでもログインすることができる
ポリシーを自作することも可能（「ポリシー」作成画面ではビジュアル作成とJSONがタブで切替可能）
パスワードポリシー
・強いパスワード＝高いセキュリティ
・AWSでは、パスワードポリシーを細かく設定できる
最小文字数の設定
必要な文字種別（大文字、小文字・数字・記号）
・一定期間が過ぎたらパスワード変更を必須に（パスワード有効期限を設定）する
・パスワードの再利用の禁止
IAM＞アカウント設定＞パスワードポリシー
デフォルトのパスワードポリシー
パスワードの最小文字数：8 文字
パスワードの強度：次の文字タイプのうち、少なくとも 3 つを含めてください: 大文字 小文字 数字 英数字以外の文字
その他の要件：パスワードの有効期限なし、AWS アカウント名や E メールアドレスと同じにすることはできません
多要素認証（Multi Factor Authentication – MFA）
MFA＝パスワード（you know）＋セキュリティデバイス（you have）
MFAデバイス
バーチャルMFAデバイス（Google Authenticator、Authy等）１デバイスで複数トークンをサポート
Universal 2nd Factor（U2F）Security Key（Yubikey by Yubico等）1キーで複数のルート・IAMユーザをサポート
Hardware Key Fob MFA Device （Gemalto製品等）
Hardware Key Fob MFA Device for AWS GovCloud(US) （SurePassID製品等）
MFAの設定
AWSへのアクセス方法（3つ）
・AWSマネジメントコンソール（PW＋MFAで保護）通常のWebブラウザ経由
・AWS Command Line Interface（CLI）（アクセスキーで保護）
・AWS Software Developer Kit（SDK）（アクセスキーで保護）
IAMアクセスキーはAWSマネジメントコンソールで生成（そして自己管理）
アクセスキーID ＝ ユーザ名 に相当
シークレットアクセスキー ＝ パスワード に相当
IAMアクセスキーの作成
IAM＞ユーザー＞セキュリティ認証情報タブ＞アクセスキーを作成＞CLIを選定＞命名
※アクセスキーはユーザ毎に2つまで持てる
※PC1台に対して1つのアクセスキーを紐づけ、常に同じユーザとしてAWS CLIにアクセスすることができる
AWS CLIの最新バージョンのインストールまたは更新
Windows用AWS CLIをダウンロードしてインストール
または
コマンドプロンプトから msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi を実行
アクセスキーをAWS CLIに設定する方法
Windowsコマンドプロンプトで > aws configure を実行
AWS Access Key ID [None]: ********
AWS Secret Access Key [None]: *****************
Default region name [None]: ap-northeast-1
Default output format [None]: このままEnterでOK
※AWS ConfigureもAWSサービスの1つであるため、従量課金制で料金がかかる。※参考記事
（AWS Configureを使用中は、「設定レコーダー」というものが常時稼働している）
設定レコーダーを削除するには、AWS CLI上で delete-configuration-recorder を実行する。ってどこでやるの？
Cloud Shell の使い方
サービス向けIAMロール
サービスの中には、自分の代わりにアクションを実施する必要があるものがある。
例えばAdministratorsAccess許可ユーザが作成したEC2をそのまま稼働させていると、そのEC2インスタンス自体もAdmin権限を持ってしまい、全AWSサービスにアクセスできてしまうことになる。（最小権限の法則に反する）
回避するために、コンポーネントに対してIAMロールを紐づけることができる。
例）EC2インスタンスロール、Lambdaファンクションロール、CloudFormation向けのロール
例）EC2向けIAMロール
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
IAMセキュリティツール
IAM Credentials Report（アカウントレベル）
IAM＞認証情報レポート
すべてのアカウントのユーザや認証情報の状態をレポート
ユーザを作った日付、PWやMFAが有効になっているか、PWがいつ使われたか等のcsvファイルをDL
IAM Access Advisor（ユーザレベル）
IAM＞ユーザー＞アクセスアドバイザー
ユーザに許可されているサービスと、それぞれのサービスに最後にアクセスしたのがいつかがわかる
権限を見直すのに使える
IAMガイドライン＆ベストプラクティス
・AWSアカウントのセットアップ以外では、ルートアカウントを使わないようにしよう
・１物理ユーザ＝１AWSユーザにしよう
・ユーザをグループに割り当て、権限をグループに割り当てよう
・強いパスワードポリシーを設定しよう
・MFAを使い、できれば必須にしよう
・AWSサービスに権限を割り当てるためにロールを使おう
・CLI/SDKのアクセスではアクセスキーを使うので忘れずに
・IAM Credentials Reportで権限を管理しよう
・決してIAMユーザやアクセスキーを共有しないこと！
IAM サマリー
・ユーザ：物理ユーザに対応、パスワードを持つ
・グループ：ユーザを含む（グループの入れ子は不可）
・IAMポリシー：ユーザ、グループの権限を書くJSONドキュメント
・ロール：EC2インスタンスやAWSサービスなどで利用
・セキュリティ：MFA＋パスワードポリシー
・アクセスキー：CLI、SDKでアクセスする時に利用
・監査：IAM Credentials Report & IAM Access Advisor
AWS STS（Security Token Service）
外部クライアントが一時的にAWSリソースの認証を受ける仕組み
IAM ＞ アカウント設定
