AWS IAM(AWS Identity and Access Management)
Overview
AWSサービスをよりセキュア(安全)に利用できるように認証と認可の仕組みを行う権限管理サービス。
認証は本人性の確認(Authentication)
認可はリソースアクセスへの利用権限の付与(Authorization)
IAMの機能は大きく分けて以下の4つになる。
- IAMユーザー
- IAMユーザーグループ
- IAMロール
- IAMポリシー
参考
初心者にも分かりやすいIAM入門～ロールとグループとポリシーの違い,設計・設定手順について～
AWSセキュリティのベストプラクティス（reference）
iamベストプラティクス
AWSにおけるクレデンシャル
多分普通に作る流れのやつ
ルートユーザー
ルートユーザーを使用しないことです。
代わりに、最初のIAMユーザーを作成するためにのみ、ルートユーザーを使用するのがベストプラクティス。
AWSを使い始める際、サインアップの時にメールアドレスとパスワードを登録します。
これがAWSアカウントのパスワード
AWSアカウントというのは権限制御ができない。
言い換えれば、常にそのアカウント内のリソースに対する全権を持つ。
つまり、AWSアカウントとしてAWSにログインするのは危険。
IAMユーザー
IAMユーザーは、AWSを操作するために使用する利用者単位のID。
従業員毎の個別アカウントをイメージすれば問題ない。
デフォルトでは何の権限も設定されていない。
IAMユーザーは必ず利用者ごとに作成するのがポイント
複数の人が共通で使用できてしまうと後で誰がこの操作をしていたのか追跡することが不可能になるため、共有はしてはいけない。
- AWSでアカウントを作る（ルートユーザー）
- ルートユーザーでIAMユーザーを作成する（admin権限で）
- admin権限で操作を今後する。人によってIAMユーザーを作ってあげる
- サービスごとのロールをアタッチする。
IAMユーザーは長期的な認証情報であるアクセスキーを生成可能。
IAMユーザのパスワード
また、IAMのManagement Consoleにおいてユーザを作成した場合、そこで設定したパスワードがIAMユーザのパスワード
これに対して、IAMユーザは設定により権限を制御可能。
たとえ管理作業を行う場合でも、別にIAMユーザを作成し、そのIAMユーザに管理権限を与えて、普段はIAMユ ーザを利用すべき。
IAMユーザのAPIキー
IAMのManagement Consoleにおいてユーザを作成した場合、そこで生成したアクセスキーが「IAMユーザのAPIキー」
そしてAWSのAPI操作のために必要なアクセスキーとシークレットキーをクレデンシャル情報と呼ぶ。
IAMユーザーから生成したアクセスキーをサービスの env などに配置するのは重大なインシデントにつながる可能性があるので、サービスにはIAMロールを設定する。
そのためIAMユーザーのアクセスキーは決して他者に共有することなく、定期的にローテーションすることが推奨されている
IAMユーザーグループ
大規模なシステム開発・運用する場合、IAMユーザーを利用者毎に設定していくのは大変。
そのため、同じ権限を持った複数のIAMユーザーをまとめて管理したい場合にIAMユーザーグループを作成する。
各IAMユーザーをグループに所属させ、グループにIAMポリシーを割り当てることで、グループ単位で役割別の権限設定ができます。
なお、IAMユーザは複数のグループに所属できます（最大10グループ）
IAMロール
IAMロールとは、EC2インスタンスやLambda関数などのAWSリソースへ権限を付与する機能。
IAMロールにはIAMポリシーを複数付与して権限をひとまとめにできる。
IAMポリシーはIAMユーザーに直接付与できますが、IAMロールはIAMユーザーだけでなく、EC2インスタンスやLambda関数(後述)などのAWSリソースにも付与できる。
デフォルトで用意されているロールがあるがそれは基本使わない。
自分達でロールは作成するのがベスト。
IAMユーザーへの付与
IAMロールは1つのIAMユーザー・AWSリソースに対し、1つしか割り当てられない。
たとえば「開発者」が使用しているIAMユーザーを「運用者」の権限に変更したい場合、IAMロールを切り替えることで変更できる。
この切り替え(IAMロールを引き受けること)をAssumeRoleという。
PassRole
IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた
AssumeRole
IAMユーザを作成してCredentialを発行しなくても、一時的にAWSリソースへのアクセス権限を得る事が可能な仕組み（sudoみたいな）
EC2などにIAMロールをアサインした際にも内部で同一の処理が発生している。
AWSリソースへの付与
利用者を介さずに「AWSリソースがAWSリソースを操作したい」ケースもある。
たとえば、EC2とS3、EC2とLambda関数のようなAWSリソース同士を操作するケースでは、IAMロールを使用することで、AWSリソースに権限を付与できる。
最小権限の原則
IAMロールを使用することで、アクセス許可を長期的にではなく一時的に付与できるため、AWSサービスに権限を付与するときはIAMロールの使用が推奨されている。
理由は、IAMユーザーは長期的な認証情報であるアクセスキーを生成可能だが、万が一アクセスキーが流出してしまうと第三者に悪用される可能性があるため。
そのためIAMユーザーのアクセスキーは決して他者に共有することなく、定期的にローテーションすることが推奨されている。
また不要になったアクセスキーは無効にするか削除する。
一方、IAMロールのアクセスキーはホテル宿泊時に一時的に渡されるホテルキーのようなイメージ。
AWS STS(Security Token Service)
IAMロールが一時的な認証を行える仕組みは、AWS Security Token Service(以降STSと表記)という機能を使って成り立っている。
STSとは一時的な認証情報を与える機能で、数十分〜数時間のみ有効な認証情報を発行する。
発行する認証情報は以下の3つ。
- アクセスキー
- シークレットアクセスキー
- セッショントークン
STSは認証情報さえあれば、利用者やアプリケーションに対し、IAMユーザーを作成する必要がない。
そのため、一時的にリソースアクセスさせたい利用者や、アプリケーションがある場合にとても有効な機能。
IAMポリシー
[初心者向け] IAMカスタムポリシーを最初から作る方法の一つ
IAMポリシーはAWSリソースへのアクセス権限の制御(誰が、どのサービスの、どのような操作を、許可または拒否するか)をJSON形式で記述したもの。
IAMポリシーの定義方法としては、主に次の図のようなホワイトリスト/ブラックリストの2パターンがある。
よくあるパターンのIAMポリシーは事前にAWSで用意されている。
IAMポリシーには以下の種類がある。
- AWS管理ポリシー AWS側が提供するポリシーであり、ポリシー単体で存在する。 管理者権限などがサービス毎に用意されており、複数の対象に付与することが可能。
- カスタマー管理ポリシー ユーザー側で作成・管理するポリシーであり、ポリシー単体で存在する。 バージョンの管理が可能なため、もし設定に誤りがあった場合には以前のバージョンの権限に戻すことができる。 接続元IPアドレスなどの制限を設定できるため、AWS管理ポリシーと比べて細かい権限を設定する際に有効的。
- インラインポリシー ポリシー単体では存在できないポリシー。 付与対象とは1対1の関係になるため、複数の対象に付与できない。 基本的にはインラインポリシーは管理が複雑になるため、管理ポリシーを使用することが勧 められる。
IAMポリシーを付与する対象別に以下の種類に分類できる。
- アイデンティティベースのポリシー アイデンティティベースのポリシーとは、IAMユーザー、IAMユーザーグループ、IAMポリシーのこと
- リソースベースのポリシー リソースベースのポリシーとはAWSリソースに付与するポリシーのこと。 リソースベースのポリシーでは、インラインポリシーのみ設定できます。 つまり、AWS側で用意されるポリシーの雛形はなく、用途に合わせて記述する必要がある。 リソースベースのポリシーでは、追加でPrincipalステートメントを指定する必要があります。 PrincipalステートメントとはAWSアカウントおよびルートユーザー、IAMロール、IAMユーザーなどのアクションを実行する主体を指します。
アイデンティティベースのポリシー例
リソースベースのポリシー例
IAMその他の機能
クロスアカウントアクセス
アカウントを跨ってリソースにアクセスしたいとき、クロスアカウントアクセスという機能があります。アクセスしたいリソースにIAMロールまたはリソースベースのポリシーを割り当てることで、アカウント間のアクセスを可能にします。
