脱IAMユーザー! IAM Identity CenterとTEAMでセキュアにAWSを利用する

こちらの記事はJapan AWS Ambassadors Advent Calendar 2023の6日目の記事になります。

 

マルチアカウントでIAMユーザーの管理したくない

 

西山です。

「IAMユーザーの管理大変」「いつの間にかしらないIAMユーザーができててアクセスキー発行してるし何に使っってるかわからない」「社員の入退社のたびに作業が必要」などなど…そう思ったことはないでしょうか?

個人の端末でAWS CLIを利用するためにIAMユーザーとアクセスキーは必要と考え、申請した人にIAMユーザーを発行していましたがいつの間にかすごい数になっちゃってたり・・・。

上記は社内のAWS管理者として私が実際に経験したことですが、やっと2023年にIAMユーザーフリーな環境をつくることができたので紹介したいと思います。

 

最初にまとめ

 

  • IAM Identity Centerを利用してAWSコンソールアクセスユーザー、CLIユーザーを管理する
  • 外部IdP連携を使うとさらにヨシ
  • アカウントにSSOする際に利用するIAM Role(許可セット)にはIAMユーザー周りの操作権限を与えない
  • 本番アカウントなど一時的なアクセス権限が必要なときはTEAMを利用して簡単・安全に権限付与する
  • AWS CLIのConfigは共通化して配布することで運用負荷軽減

 

できるようになること

 

IAM Identity Centerを介して各AWSアカウントへIAMユーザーを利用せずにSSOアクセスができるようになります。

ユーザーごとにアクセス可能なアカウントはIdentity Centerで一元管理することができます。

 

SSOアクセスはAWSマネジメントコンソールだけに限らず、SSOの認証情報を利用してユーザーの端末からCLIアクセスも行うことができます。

 

 

アカウント利用者はTEAMを介してアクセス許可されていないアカウントへの一時的なアクセス権限を申請することができます。

アカウント管理者が申請を承認することで申請者は対象のアカウントへ一時的にアクセス可能になります。申請時に指定した時間が経過すると自動的にアクセス権限はなくなります。

 

 

IAM Identity Center(旧AWS SSO)

 

今回の要となるサービスです。

今回は組織でAWS Organizationを利用しマルチアカウント管理をしている前提となりますが、IAM Identity Centerを利用することで、メンバーアカウントへのアクセスや外部のAWSアカウントやアプリケーションへのSAML認証によるアクセスを一元管理することができます。

メンバーアカウントへのアクセスは、マネジメントコンソールアクセスとCLIアクセスがそれぞれ用意されています。

CLIアクセスについては後述します。

 

 

外部IdP連携を利用する

 

IAM Identity Center単体でもSSO基盤 + IdPとして利用可能ですが、Azure ADやGoogle Workspaceといった組織で利用しているIdPと連携することもできます。

対応している外部IdPであれば、Identity Centerへユーザー作成、削除をしなくても自動的にユーザー情報が同期され、アクセス権限範囲のみを付与すれば良くなり運用性が上がります。また、ユーザーを二重管理する必要がなくなり、SAMLでIdentity Centerへ認証することができるためセキュリティ面でもメリットがあります。

 

一点、Google Workspaceはブログ執筆時点でユーザーの同期はできますがグループの同期ができないため、下記ブログのように自分でグループを管理する必要があります。

AWS CDKでIAM Identity Centerのグループを管理する

 

許可セットについて

 

各メンバーアカウントへアクセスする際にどういった権限を付与するか(認可するか)といった設定が許可セットになります。アクセスする際に利用するIAMロールの指定です。

この許可セットで大事なことは、「IAMユーザーおよびアクセスキーの作成、更新、削除を禁止する」ことです。

この予防的統制を入れることで今後管理対象外のIAMユーザーが増えることを防ぐことができます。

 

TEAM

 

AWSアカウントへのアクセス管理で課題になりやすいのが一時的なアクセス権限の付与です。申請、承認、権限付与を手動で行うととても手間がかかります。

TEAMを利用することで上記の手間を自動化し、アクセス権の申請と承認のみを行うだけで一時的なアクセス権を付与することができます。

実際の画面を見たほうがイメージが付きやすいと思うので下記のサイトでご確認ください。

TEAMについて(動画はこちら)

 

また、アップデートによってTEAMがSlackやAmazon SNSへの通知に対応したため、より使いやすくなりました。

 

導入方法

 

導入もとても簡単です。リポジトリをプルしてパラメーターを入力しスクリプトを実行するだけなので1時間かからずに導入できます。

以下が公式デプロイ手順リンクとなります。

TEAMの導入方法

 

またTEAMの設定はギークフィードでは以下のようにしており、最大でも24時間の一時的なアクセス権限を申請できるようにしています。

また通知はメールでは気づきにくいためSlackのみとしており、問題なく運用できています。

 

 

TEAM設定Tips

 

システム管理者(アカウント管理者)は常にすべてのアカウントへのアクセス権限を持つべきではなく、他のユーザーと同じように必要な時にのみアクセス権を申請すべきです。

ですが、TEAMは自分の申請を自分で承認することができません。

対策として、Eligibility Policyで管理者グループは承認(Approval Required)をNoとすることで対策しています。

 

この設定により管理者も都度必要な時に即座に一時的なアクセス権限を申請することができます。

また、管理者のみIAMユーザーを操作可能な許可セットを申請できるようにすることで、ユーザーが管理対象外のIAMユーザーを作成することを抑制しています。

 

 

AWS CLIの設定

 

AWS CLIを利用する際、IAMユーザーであればCLIのconfigにアクセスキーとシークレットアクセスキーを記載するというやり方でしたが、IAM Identity Centerを利用していればそんな必要はありません。

AWS CLI v2はIAM Identity Centerと連携しIdentity Centerでアクセス可能なアカウントに対してCLI可能です!

 

AWS IAM Identity Center を使用するために AWS CLI を設定する

 

CLIのConfig

 

ユーザーそれぞれアクセスできるアカウントは異なりますが、configファイルには認証情報が一切入っていないので、すべてのアカウントの設定を記載したAWS CLIのconfigファイルを社内配布することができます!

Configファイルを一元管理できるので、人によってプロファイル名が違ったりアカウントがなかったりといった運用上のトラブルも防ぐことができます。

実際の配布方法は以下のブログを参照ください。

 

複数のAWS SSO(IAM Identity Center)をAWS CLIに関連付ける&社内運用Tips

 

まとめ

 

今回はIAMユーザーを利用せずに組織内でAWSを運用する方法についてまとめました。

これまで何年も試行錯誤して色々管理の方法を変えたりしてきましたが、やっと納得のいく現実的に運用可能な構成のベースができました。

もちろん今回紹介した設定は100点満点のものではなく、より細やかな許可セットの設定などがあるとは思いますが、IAMユーザーとアクセスキーを利用していた頃と比較して大幅な改善となりました。

最初から100点を目指すのではなく、ラクに効率よく改善できるところから手を付けてマイナスをゼロに近づけていくことが大事だと思います。

 

明日のアドベントカレンダーはコミュニティ界の三冠王、山口さんの記事です。お楽しみに〜。

 

採用宣伝

 

ギークフィードではAWSエンジニアなどの職種で一緒に働く仲間を募集しています。

弊社に興味を持っていただいたり、会社のことをカジュアルに聞いてみたいという場合でも、ご気軽にフォームからお問い合わせください。その場合はコメント欄に、カジュアルにお話したいです、と記載ください!

採用情報はコチラ

 

この記事が気に入ったら
いいね ! しよう

Twitter で

【採用情報】一緒に働く仲間を募集しています

採用情報
ページトップへ