AWS IAM
#AWS
https://gyazo.com/2f4406d4c6e30fe31c52ec60619136a4
IAM (AWS Identity and Access Management) とは、AWS ユーザーに対して AWSのリソースへのアクセスできる範囲やアクセス方法を安全に制御する ためのウェブサービス。その種類は以下。
table:iam
IAM リソース 概要
IAM User AWS を利用するアカウントに相当する
IAM Group IAM User をまとめて管理する
IAM Role AWS サービス、アプリケーション等に対して AWS の操作権限を付与する
IAM Policy AWS リソースに対する権限を設定する。
IAM Policy にアクセス許可が定義され、それを IAM User, IAM Group, IAM Role, (AWS リソース) に適切にアタッチし、利用する。
https://gyazo.com/12ca05fa83ea8424cd8fc12a79779f65
IAM User と IAM Role は、どちらも AWS のリソースに対するアクセス許可を持つリソースだが、 用途が異なる。
IAM User
AWS を利用する人間が AWS を操作するときに利用する IAM リソース
IAM Role
AWS リソースが AWS を操作するときに利用する IAM リソース
http://dev.classmethod.jp/?p=176420
http://dev.classmethod.jp/?p=152401
IAM User
https://gyazo.com/272f9d8ec07ec7a1b7a436abbf2e8bfc
IAM User の中でも、初期に発行されるルートユーザアカウントは、流出するととんでもないことになるので、
MFA を利用する
基本的には別 IAM User を作成しそちらを利用する
と、良い。
MFA (Multi-Factor Authentication)
通常のアカウントパスワードに加えて、ワンタイムパスワードを使用してセキュリティを強化する仕組みのこと。
https://aws.amazon.com/jp/iam/details/mfa/
https://e-book-info.com/how-to-set-mfa-of-aws/
IAM Role
IAM Role は、リソースへのアクセスを委任するために使用される。
一時的なアクセスを提供
静的な AWS 認証情報の必要性を排除
アクセスキー/シークレットキーや、メールアドレス/パスワード等の認証情報を不要にする
ユースケース
AWS リソース権限をアタッチ
外部で認証されたユーザにアクセスを許可
第三者にアクセスを許可
AWS EC2 や AWS Lambda 上で動作するアプリケーションに IAM User のアクセスキーを渡すのは、アクセスキー流出の恐れを孕むためアンチパターンである。
IAM Role をアタッチすると、AWS EC2 や AWS Lambda 等の AWS リソースのメターデータから、一時的な認証情報を取得できる。これをアプリケーションに利用させることで、アクセスキー流出の恐れをなくすことができる。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
https://gyazo.com/843bff0abc5461700d6859e527ffab8e
さらに詳しい話をすると、この時の 一時的な認証情報 の生成には、Amazon STS が利用されている。IAM Role には AssumeRolePolicyDocument という設定項目があり、ここに信頼する対象が埋め込まれる。例えば、AWS EC2 に IAM Role をアタッチした場合は、該当の EC2 インスタンスが信頼対象である。
その後、該当 EC2 インスタンスの認証情報取得用のエンドポイント http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name にアクセスすると、EC2 により sts:AssumeRole が実行され、STS の AssumeRole API を叩く。これは IAM Role の ARN を入力として、アクセスキーを取得できる API である。この時帰ってきたアクセスキーを利用して、AWS リソースにアクセスできる。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp.html
ほかにも、Amazon Cognito と組み合わせることで、Facebook アカウントを認証することや、特定の AWS アカウントを認証 (クロスアカウントアクセス) することもできる。
http://blog.serverworks.co.jp/tech/2018/02/16/understarnd_iam_role/
IAM Policy
1つないし複数のアクセス許可を定義し、IAM Group/User/Role もしくは AWS リソースにアタッチできる。
アクセス許可は、デフォルトでは Deny に設定される。明示的な許可、拒否が設定されていた場合、それらが優先して適用される。ただし、競合が発生した場合は最も制限の厳しいポリシーが優先される。例えば、Allow よりも Deny の方が制約が厳しいため、単純に同一の対象に Allow, Deny の両方が設定されていた場合は、Deny が優先される。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies.html
その他セキュリティについて
AWS リソースにはタグ付けができるので、それを利用してポリシーを構築するという手がある。
https://aws.amazon.com/jp/blogs/news/new-aws-resource-tagging-api/
以下はあとで読む。
https://yoshidashingo.hatenablog.com/entry/2014/08/24/211825
フェデレーティッドユーザ
ID ブローカー アプリケーションを作成する
認証基盤で認証を行う
AWS STS の AssumeRole API を叩く
その他気になること
アクセス制御についてもまとめる
https://dev.classmethod.jp/cloud/aws/ec2-cacess/
#AWS