• 長期的認証情報と一時的な認証情報の両方の利用が可能な場合には一時的なものを利用するようにする ◦ IAM User と IAM Role 両方で実現可能であれば IAM Role を利用する ◦ 長期的な認証情報はなくすことはできないが、管理が大変なのでなるべく増えないような構成が良い • ユーザーアカウントの認証にはMFAを必須とする ◦ AWSでいうと具体的には IAM User / Root User • アカウント・ユーザーを複数人で共有しない ◦ 便利だからとユーザーアカウントを複数人で共有してはいけない ▪ 多くの場合、サービスの利用規約に抵触する ▪ ログのトレーサビリティが下がってしまう • メンバーA/B/Cの三人が一つのユーザーアカウントXを共有していたとする • Xのログを見た際に、どのメンバーが実施したのかが分からなくなる 認証認可のベストプラクティス
徹底入門 • IAM のリソース（後述） ◦ Root user ◦ IAM User ◦ IAM Group ◦ IAM Role ◦ IAM Policy • Request 関係（後述） ◦ Request ◦ Actions / Operations ◦ Principal ◦ Environment data ◦ Resource data • AWSアカウント ◦ AWSのリソースのコンテナのことで、テナントと言い換えても良い ◦ 一般的にアカウントというとユーザーアカウントの意味が多く IAM User が対応するが AWSアカウントというと全く別物なので「アカウント」という単語の使い方には要注意 IAM の用語
徹底入門 AWSへのアクセス時の主語となるもの • IAM User ◦ AWSを利用するユーザーやアプリケーションを表すエンティティ ◦ user名と認証情報（コンソールパスワード・アクセスキー）で構成される ▪ 認証を強固にするためにMFAを設定することができる（推奨） ▪ IAM User の認証情報は長期的なもの • IAM Role ◦ AWSアカウントで作成できる特定のアクセス権限を持ったIAM Identityのこと。 ◦ 認証の基礎となるAWSリソースという意味ではIAM userと似ているが、以下のいくつかの点で異なる。 ▪ IAM Userは基本的に1人の特定の人が利用することを想定しているが、 IAM roleは必要とする任意の人が利用できるように設定できる ▪ IAM Userは長期的な認証情報（パスワードやアクセスキー）で認証を行うが、 IAM Roleは一時的な認証情報で認証を行う • IAM Group ◦ IAM User をグループ化したもので、Userへのポリシーのアタッチを容易にするための機能 • Root User ◦ AWSアカウントをはじめて作成した時にされるユーザーのこと ◦ Root User は最も強い権限を持っているためなんでもできてしまう ◦ そのためMFAの設定だけして普段は基本的に使わないことが推奨されている IAM User / Role / Group and Root User
徹底入門 • IAM User や AWS サービスが Assume Role で特定の IAM Role を引き受けたセッションを作成することで、 ユーザーやシステムがAWSのリソースを（Roleが持つ権限の範囲で）利用できるようになる • "assume role" は「roleを引き受ける」みたいなニュアンス ◦ 特定の役割をもった帽子を被り、 その役割の権限は適宜使えるようになるみたいなイメージ • Assume Role を実行すると以下の３つからなる一時的な認証情報が 返却され、これを利用することで一定期間認証ができるようになる。 ◦ Access Key ◦ Secret Access Key ◦ Session Token • Assume Role を実行できる人は、実質 IAM Role の権限を使える人 ということになるので適切に制限する必要がある ◦ IAM Role の Resource based policy である 信頼ポリシーに「誰がAssume Roleをできるか」を 記載することで制限する Assume Role AWS再入門ブログリレー2022 AWS IAM編 より
徹底入門 認証情報には長期的なものと、一時的なものがある • IAM User : 長期的な認証情報 ◦ その名の通り有効期限が数ヶ月などと長いものから、場合によっては有効期限がないような認証情報 ◦ ユーザーが保存し適宜利用することになるため、管理が大変 ◦ 具体例：IAM User のコンソールパスワード • IAM Role : 一時的な認証情報 ◦ その名の通り有効期限が非常に短く、数分から数時間で失効するような認証情報 ◦ 一時的な認証情報はユーザー側で保存されることはなく、ユーザーのリクエストに応じて動的に生成する ◦ 一度作った一時的な認証情報が失効してしまったら再度新しい一時的な認証情報を作ってもらう ▪ 失効したものが再利用されることはない ◦ 具体例：IAM Role が利用する一時的な認証情報 IAM Role が使える場合にはなるべく IAM Role を使っておくのが良い User vs. Role 〜長期的認証情報と短期的認証情報〜
/ Role / Policy などを作成する時に必ず一意のID（例：AIDAJQABLZS4A3QDU576Q ）を割り当てる。 普段はユーザーフレンドリーなARN形式を利用するのであまり見ないが、ログなどにはこのIDが現れたりする。 このprefixはリソースの種類ごとに以下のように決まっている。 • AIDA : IAM User • AROA : IAM Role • AKIA : Access Key • ASIA : Temporary access key ID • … https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids より IAM ID
kevinrobot34
kimpetersen
eitanlees
baasie
skipperchong
tammyeverts
samanthasiow
katarinadahlin
sabderemane
427marketing
techseoconnect
akademiya2063
