AWS - IAM

IAM紹介

ユーザーアカウントの管理が主な目的であり、 ユーザーを管理し、アクセスレベルと権限を管理できる権限管理ソリューションです。

すべてのAWSに対してきめ細かいアクセス制御を提供します。 IAMを使用すると、サービスとリソースにアクセスできるユーザーとアクセス条件を指定できます。 IAMポリシーで人員とシステムの権限を管理し、最小権限を保証できます。

AWS IAMダッシュボードに記載されている説明です。 IAMはIdentity and Access Managementの略で、鍵の形のロゴを使用しています。

IAMはルートアカウントより低い、または制限された権限を持つサブアカウントを管理するサービスです。 利用料金は無制限で無料であり、アカウント作成にも制限はありません。

IAMの必要性

IAMがAWSにアクセスできるユーザーを管理するサービスであることがわかりました。 では、なぜ複数のアカウントを追加で作成し、わざわざ最小権限で維持・管理する必要があるのでしょうか？

正確ではありませんが、私が理解したことをもとに一つの仮定をしてみましょう。 あなたが会社を運営しているとします。うーん...CTOだと仮定しましょう。 そして、その会社がクラウドを利用したサービスを、特にAWSを利用してサービスを提供しているとすると、 会社のAWSルートアカウントを作成するでしょう。 まだよくわかりませんが、おそらく法人カードのようなものを使用するアカウントを作成するでしょう。 会社にはさまざまな開発部署があるでしょう。 それぞれ異なる部分の開発を担当する部署で管理すべきAWSリソースは異なるでしょう。 ある部署が必要以上の管理権限を得ると、その必要もないし、誤ったアクセスで他の部署のサービスを壊してしまう可能性もあります。

また、あなたがあるサービスを開発していて、何らかの理由で.envファイルにAWSアクセスキーを書いていたとします。 そしてGitHubにアップロードするとき、.gitignoreファイルの作成を忘れて、そのまま.envファイルをアップロードしてしまったら... さらにIAMを使用していなくてルートアカウントのアクセスキーが漏洩したら、このような記事の主人公になる可能性があります。

もちろん状況が異なる場合もありますが、ハッキングやミスでキーが漏洩したという点は共通しています。 このような状況を予防したり被害を軽減するためにIAMが存在します。

ここまでがIAMユーザーアカウントがなぜ必要かについての仮定でした。

IAM認証情報タイプ

IAM AWS認証情報タイプには2種類あります。 アクセスキーを使用するプログラムによるアクセス、パスワードを使用するAWS管理コンソールアクセス 今後、それぞれキー方式、パスワード方式と呼びます。

2種類のタイプを同時に選択することもでき、使用目的と環境に応じて選択すればよいです。

IAM - パスワード方式

AWS管理コンソールにアクセスするためにパスワードを認証手段として使用します。

IAMユーザーアカウントは、ルートアカウントのようにWebダッシュボードにアクセスしてサービスをコントロールしますが、 アカウントに対するすべての権限を持つルートアカウントとは異なり、ルートアカウントまたは上位権限グループで適用された制限された権限で管理できます。

IAM - キー方式

AWS API、AWS CLI、AWS SDKにアクセスするためにアクセスIDとシークレットアクセスキーを認証手段として使用します。

プログラムによるアクセスのみが有効な場合、管理コンソールにはアクセスできませんが、API/CLI/SDKで与えられた権限の操作を実行できます。 通常、IAMを初めて接するのはこの方式でしょう。 （AWS CLI入門、AWS SDKを使用したプログラミング...パスワード方式に比べて使用がほぼ強制されるため）

IAMアカウント管理を楽にするもの

IAMには数多くの権限が存在し、組織が大きくなるほど特定のグループで共有する権限、特定のユーザーに必要な特殊な権限などが生まれます。 複雑になりがちなIAMアカウント管理を助ける機能を見てみましょう！

ユーザーグループ

ユーザーグループはIAMユーザーのコレクションです。グループを使用してユーザーコレクションの権限を指定できます。

ユーザーをまとめたグループ 文字通り、類似の役割を共有するユーザーを一つにまとめ、グループに共有するポリシーを設定しておくと、ポリシーをグループ単位で管理できるようになります。

ユーザー

IAMユーザーは、アカウントでAWSとやり取りするために使用される長期認証情報を持つIDです。

実際にアクセスする手段を提供するもの 後で説明するロールと対照的に、長期認証情報を持っています 自分が所属するユーザーグループのポリシーとユーザー固有の権限が適用されます

ロール

IAMロールは、短期間有効な認証情報を持つ特定の権限があるIDです。信頼できるエンティティがロールを引き受けることができます。

正直よくわかりません。 ユーザーが存在し、そのユーザーに十分な権限があれば、作業に必要なロールを委任されて必要な作業を実行し、作業が終わったらロールを返す...そのような一時的な権限を指すようです。 後でIAMロールだけ別途投稿してみようと思います。

ポリシー

ポリシーは権限を定義するAWSのオブジェクトです。

ポリシーはAWSリソースにアクセスできるユーザーとそのリソースで実行できる操作を指定したJSONドキュメントです。 IDまたはリソースにポリシーをアタッチして権限を定義できるそうです。 うーん...これもポリシーの書き方で別途投稿してみます。