AWS 環境への一時的な昇格アクセスの管理

本記事は Managing temporary elevated access to your AWS environment を翻訳したものです。

この投稿では、一時的な昇格アクセスを実装することによって、AWS 環境へ人がアクセスすることに伴うリスクをどのように軽減できるのかについて学びます。また、最小限のリファレンス実装をダウンロードすることができ、それを出発点として、あなたの組織に合わせた一時的な昇格アクセスソリューションを構築することができます。

概要

最新のクラウドアーキテクチャの多くは、人によるアクセスを排除することを目指していますが、少なくとも人によるアクセスが必要なケースが残っていることはよくあることです。例えば、予期せぬ問題が発生した場合、診断や修正に人の手が必要になることがあります。また、レガシーテクノロジーを AWS 環境に導入した場合に、誰かが手動で設定しなければならないこともあります。

AWS はアクセス管理のための豊富なツールと機能を提供しています。ユーザーは多要素認証（MFA）で認証し、外部 ID プロバイダーを使用してフェデレートし、制限された権限で一時的な認証情報を取得することができます。AWS Identity and Access Management (IAM) はきめ細かいアクセス制御を提供し、AWS Single Sign-On (AWS SSO) は AWS Organizations を使用して組織全体のアクセスを簡単に管理することができます。

人がアクセスを実施するシナリオの場合にはリスクが高まるため、組織は一時的な昇格アクセスを実装することで、ベースラインのアクセス制御を補完することができます。

一時的な昇格アクセスとは

一時的な昇格アクセスの目的は、ユーザーがアクセスを呼び出すたびに、そのアクセスに対してビジネス上の適切な理由があるかを確認することです。例えば、ビジネス上の適切な理由とは、特定の問題を修正するため、または計画された変更を展開するため、などです。

従来のアクセス制御システムでは、保護されたリソースにアクセスする前にユーザーが認証され、認可されることが必要でした。認証されるのは通常1回だけで、ユーザーの認証状態はアクセス再認証プロセスを通じて定期的に確認されます。

永続的アクセス（常時アクセスとも呼ばれる）では、認証および認可されたユーザーは、保護されたリソースに対する操作を実施するだけで、いつでもアクセスを呼び出すことができます。アクセスを呼び出すプロセスでは、その都度、呼び出す理由を考慮することはありません。現在、永続的アクセスは AWS Single Sign-On がサポートするモデルであり、IAM ユーザーやフェデレーテッドユーザーで最もよく使われているモデルです。

一時的な昇格アクセス、別名ジャストインタイムアクセスでは、ユーザーは以前と同様に認証と認可を受けなければなりませんが、さらに、ユーザーがアクセスを呼び出すたびに、その特定のアクセスを呼び出すことに対するビジネス上の理由を記録することを目的とした追加のプロセスが実行されます。このプロセスには、さらに人が関与する場合もあれば、自動化されたプロセスが使用される場合もあります。このプロセスが完了すると、ビジネス上の理由が適切であり、アクセスの範囲と期間がビジネス上の理由と一致している場合にのみ、そのユーザーにアクセスが許可されます。

なぜ一時的な昇格アクセスを使用するのか

一時的な昇格アクセスは、人がアクセスを実施するシナリオのうち組織が高リスクとみなすものについて、リスクを軽減するために使用することができます。一般的にアクセスにおいてリスクが発生するのは、設定の変更、権限の変更、データの読み取り、データの更新などの高いレベルの権限と、本番環境、重要なサービス、機密データなど価値の高いリソースの２つの要素が重なったときです。これらの要素を使用してリスク閾値を定義し、それ以上の場合は一時的に昇格アクセスを実施し、それ以下の場合は永続的なアクセスを許可し続けることができます。

一時的なアクセス制限を導入する動機は、組織のリスク選好度に基づく内部的なものと、業界に適用される規制要件などの外部的なものが考えられます。組織に規制要件がある場合、お客様側でその要件を解釈し、一時的な昇格アクセスソリューションが必要かどうか、またどのように運用すべきかを決定する責任があります。

どのような要件であっても、全体的な目標はリスクを低減することです。

重要：一時的な昇格アクセスはリスクを軽減しますが、望ましいアプローチは常に、そもそも人によるアクセスが必要ないように自動化することです。一時的な昇格アクセスは、まだ自動化できない、頻度の低いアクティビティにのみ使用することを目指します。リスクの観点からは、人によるアクセスが全く発生しないことが最も望ましいです。

AWS Well-Architected Framework は、自動化を用いて人間のユーザーアクセスの必要性を減らすためのガイダンスを提供しています。

OPS 6: どのようにデプロイのリスクを軽減しますか？→ 統合とデプロイを完全自動化する。
OPS 10：ワークロードと運用イベントはどのように管理しますか？→ イベントへの対応を自動化する。
REL 8: 変更はどのように実装するのですか？ → 自動化を使用して変更をデプロイする。

一時的な昇格アクセスはリスクをどのように軽減できるのか

人間の介入が必要なシナリオでは、一時的な昇格アクセスはそのリスクを管理するのに役立ちます。一時的な昇格アクセスは、アクセスガバナンス、強力な認証、セッションのロギングと監視、異常検知と対応など、標準的なアクセス制御やその他のセキュリティプロセスに取って代わるものではないということを理解することが重要です。一時的な昇格アクセスは、すでに実装されている制御を補完するものです。

一時的な昇格アクセスを使用することで、以下のようなリスク軽減効果が期待できます。

1. ビジネス上の正当な理由がある場合にのみ、ユーザーが昇格アクセスを実行する。ユーザーは、常習的に昇格アクセスを呼び出すことを避け、サービス所有者は、重要な時間帯に混乱を引き起こす可能性のあるオペレーションが実施されることを回避することができます。

2. 他の人に対するアクセスの可視化。永続的アクセスでは、ユーザーの活動は記録されますが、その活動がインシデントやセキュリティ警告を引き起こさない限り、ユーザーがアクセスを呼び出したときに誰も日常的に知らされることはありません。一時的な昇格アクセスでは、通常、すべてのアクセス呼び出しが少なくとも誰か他の人の目に入ることになります。これはその人が、承認、通知、変更のプロセスに参加しているために発生していることであり、インシデント管理プロセスなどは本来複数の当事者によって実施されるものです。より多くの人の目に入るようになれば、ユーザーが不適切なアクセスをしていることに気付き、対処できる可能性が高くなります。

3. 注意を喚起する。一時的な昇格アクセスは、ユーザーが高リスクのアクセスを実行する際に、注意を喚起するための明白な手段となります。これは、物理的なセキュリティを構築するセキュリティ対策と類似しています。安全性の高い施設に入ることを想像してみてください。障壁、フェンス、有刺鉄線、CCTV、照明、警備員、そして「あなたは制限区域に入っています」という標識が目に入るでしょう。一時的な昇格アクセスも同様の効果があります。一時的な昇格は、ユーザーに管理レベルの高さ、自分の行動が監視されていること、そして自分が行った行動に対して責任があることを思い起こさせるのです。

4. レポート、分析、継続的改善。一時的な昇格アクセスプロセスでは、ユーザーがアクセスを呼び出した理由を記録します。これは、分析し、洞察を得るための豊富なデータソースとなります。管理者は、ユーザーがなぜアクセスを呼び出しているのか、どのシステムが最も人によるアクセスを必要としているのか、どのようなタスクを実行しているのかを把握することができます。このデータを使って、自動化のための投資先を決定することができます。人によるアクセスの量を測定し、それを削減するための目標を設定することができます。また、一時的な昇格アクセスの存在は、ユーザーが一般的なタスクを自動化したり、エンジニアリングチームに自動化を依頼したりする動機付けになるかもしれません。

一時的な昇格アクセスの実装

リファレンス実装を検討する前に、まず、一時的な昇格アクセスの論理アーキテクチャを見てください。処理の流れについて、概要を理解することができます。

一時的な昇格アクセスソリューションの典型例では、ID プロバイダーとユーザーがアクセスする必要のある AWS 環境の間に、追加のコンポーネントを配置します。図1に記載された一時的な昇格アクセスブローカー(Temporary elevated access broker)と呼ばれるものが、これに該当します。

Figure 1: A logical architecture for temporary elevated access

図1: 一時的な昇格アクセスのための論理アーキテクチャ

ユーザーが AWS 環境に対して一時的な昇格アクセスを必要とするタスクを実行する場合、ブローカーを使用してアクセスを呼び出します。ブローカーは以下のステップを実行します。

1. ユーザーを認証し、妥当性を判断します。ブローカーは組織の既存の ID プロバイダーと統合し、多要素認証（MFA）でユーザーを認証し、一時的な昇格アクセスの資格があるかどうかを決定します。

注：資格は一時的な昇格アクセスにおける重要な概念です。これは、ステップ 3 で説明する追加条件を満たすことによってアクセスが呼び出される際の事前承認と考えることができます。ユーザーは通常、管理者または運用チームから信頼されたメンバーになることで資格を得ます。その資格の範囲は、職務の一部として実行することが想定されるタスクに基づいたものです。資格の付与と取り消しは、一般に、組織の標準的なアクセスガバナンスプロセスに基づいて行われます。資格は、グループメンバーシップ（ロールベースアクセス制御、すなわち RBAC を使用する場合）またはユーザー属性（属性ベースアクセス制御、すなわち ABAC を使用する場合）として表現することができます。通常の認可とは異なり、資格は、それだけでアクセスを許可するのに十分ではありません。

2. 一時的な昇格アクセスのためのプロセスを開始します。ブローカーは、一時的な昇格アクセスを取得するためのプロセスを開始する方法を提供します。ほとんどの場合、ユーザーは自分自身でリクエストを送信しますが、ブローカーの設計によっては、ユーザーがエンジニアにオペレーションを依頼するなど、他の方法でアクセスを開始することも可能です。ユーザーがリクエストするアクセス範囲は、ユーザーの資格のサブセットでなければなりません。ブローカーは、次のステップを実行するために、リクエストの背景に関する追加情報を取得する場合があります。

3. アクセスを呼び出すビジネス上の理由を確認する。ブローカーは、その特定の場面で所定の範囲にアクセスをさせることに対してビジネス上の正当な理由があるかどうかを確認しようとします。なぜこのユーザーは今このアクセスが必要なのか？ビジネス上の正当な理由を確認するプロセスは、組織によって大きく異なります。単純な承認ワークフロー、定足数ベースの承認、あるいは完全に自動化されたプロセスであるかもしれません。また、既存の変更管理システムやインシデント管理システムと統合することで、アクセスのビジネス上の理由を推察することもできます。ブローカーは多くの場合、一刻を争う緊急時にアクセスを迅速化する方法を提供します。これは、ブレークグラスアクセスの一形態です。典型的なブローカーの実装では、このステップをカスタマイズすることができます。

4. 時間制限付きアクセスを許可する。ビジネス上の理由が正当であれば、ブローカーは AWS ターゲット環境に対して時間制限のあるアクセスを許可します。ユーザーに付与されるアクセス範囲は、ユーザーの資格のサブセットでなければなりません。さらに、付与されるアクセスの範囲と時間は、最小特権の原則に基づき、前のステップで特定されたビジネス上の理由を満たすために必要かつ十分であるべきです。

一時的な昇格アクセスのための最小限のリファレンス実装

一時的な昇格アクセスの使用を開始するには、このブログ記事に付随する最小限のリファレンス実装をデプロイしてください。リファレンス実装のデプロイ、実行、拡張に関する情報は、Git リポジトリの README ページから入手できます。

注：このリファレンス実装は、IAM ユーザー、フェデレーテッドユーザー、または AWS シングルサインオンで管理する永続的なアクセスを補完するために使用することができます。例えば、AWS SSO のマルチアカウントアクセスモデルを永続的なアクセス管理に使用し、このリファレンス実装を使用して一時的な昇格アクセス用に別のロールを作成することができます。

アクセスを呼び出すためのビジネス上の正当な理由を確認するために、リファレンス実装では、シングルステップの承認ワークフローを使用しています。リファレンス実装を適用して、これを好みのワークフローやビジネスロジックに置き換えることができます。

時間制限のあるアクセスを許可するために、リファレンス実装では ID ブローカーパターンが使用されています。このパターンでは、ブローカー自身が中間的な ID プロバイダーとして機能し、条件付きでターゲットとなる AWS 環境へユーザーをログインさせ、アクセス範囲の限られた時間制限のあるセッションを許可します。

図2は、リファレンス実装のアーキテクチャを示したものです。

Figure 2: Architecture of the reference implementation

図2: リファレンス実装のアーキテクチャ

リファレンス実装がどのように機能するかを説明するために、以下のステップでは、アーキテクチャ図で強調表示されている数字を使用して、ユーザーの体験をエンドツーエンドで説明します。

プロセスの開始

あるユーザーが、AWS 環境で稼働している重要なサービスに対して特権的なアクセスが必要なタスクを実行する必要があり、そのためにセキュリティチームが一時的な昇格アクセスを設定したというシナリオを考えてみましょう。

アプリケーションの読み込み

ユーザーはまず、一時的な昇格アクセスブローカーにアクセスし、タスクを実行するために必要な AWS アクセスを要求する必要があります。

ユーザーは、ブラウザで一時的な昇格アクセスブローカーに移動します。
ユーザーのブラウザは、Amazon S3 バケットをターゲットとする Amazon CloudFront ディストリビューションから、Web 静的コンテンツを使用して Web アプリケーションをロードします。

ブローカーは、SPA（Single Page Application）と呼ばれる、ブラウザ上で動作する Web アプリケーションを使用します。

注：CloudFront と S3 は、ウェブの静的コンテンツを提供するためにのみ使用されます。ご希望であれば、プライベートネットワーク内の Web サーバーから静的コンテンツを提供するようにソリューションを変更することもできます。

ユーザーの認証

ユーザーは、認証のために組織の ID プロバイダーにリダイレクトされます。リファレンス実装では、OpenID Connect Authorization Code フローと Proof Key for Code Exchange (PKCE) を使用しています。
ユーザーは、ID プロバイダーによって署名されたアクセストークンと ID トークンを持つ認証済みユーザーとして、アプリケーションに戻ります。

アクセストークンは、ユーザーに代わってサーバー側 API を呼び出す権限をブラウザベースのアプリケーションに委任するものです。ID トークンには、ユーザーの属性とグループメンバーが含まれており、認証に使用されます。

保護されたAPIの呼び出し

アプリケーションは、Amazon API Gateway がホストする API を呼び出し、各リクエストでアクセストークンと ID トークンを渡します。
受信したリクエストごとに、API Gateway は AWS Lambda を使用して Lambda authorizer を呼び出します。

Lambda authorizer は、ユーザーのアクセストークンと ID トークンが有効かどうかをチェックします。Lambda authorizer は、ユーザーのアクセストークンと ID トークンが有効かどうかを確認し、ID トークンを使ってユーザーの身元と、グループメンバーシップに基づいて権限を決定します。

情報の表示

アプリケーションは、/get… API エンドポイントのいずれかを呼び出し、以前の一時昇格アクセス要求に関するデータを取得します。
/get… API エンドポイントは、Amazon DynamoDB のテーブルからデータをフェッチする Lambda 関数を呼び出します。

アプリケーションは、図3に示すように、過去に提出された一時的な昇格アクセス要求に関する情報をリクエストダッシュボードに表示します。

Figure 3: The request dashboard

図3: リクエストダッシュボード

リクエストの提出

一時的な昇格アクセスの資格を持つユーザーは、リクエストダッシュボードで「リクエストの作成」を選択して、新しいリクエストを送信できます。図4に示すように、ユーザーがアクセスしたい IAM ロール名と AWS アカウント ID、アクセスを呼び出す正当な理由、必要なアクセス時間を入力するフィールドがあるフォームが表示されます。

Figure 4: Submitting requests

図4: リクエストの送信

ユーザーがリクエストできるのは、グループメンバーシップに基づく IAM ロールと AWS アカウントの組み合わせに限られます。

注：ここで指定した時間は、リクエストが承認された場合にユーザーが AWS ターゲット環境にアクセスするためのセッションを呼び出すことができる時間枠を決定します。各セッションの持続時間には影響しません。セッションの持続時間は独立して設定することができます。

ユーザーが一時的な昇格アクセスの新規リクエストを送信すると、アプリケーションは /create… API エンドポイントを呼び出し、新規リクエストに関する情報を DynamoDB テーブルに書き込みます。

ユーザーは、資格のある限り、異なるロールとアカウントの組み合わせで、複数のリクエストを同時に提出することができます。

通知の生成

ブローカーは、一時的な昇格アクセス要求が作成、承認または拒否されたときに通知を生成します。

リクエストの作成、承認または拒否が行われると、通知用の DynamoDB ストリームレコードが作成されます。
ストリームレコードは、通知を処理するための Lambda 関数を呼び出します。
Lambda 関数は、ストリームレコードからデータを読み込み、Amazon Simple Notification Service (Amazon SNS)を使用して通知を生成します。

デフォルトでは、ユーザーが一時的な昇格アクセスの新しいリクエストを送信すると、承認されたすべてのレビュアーにメール通知が送信されます。レビュアーが要求を承認または拒否すると、電子メール通知が元の要求者に送信されます。

リクエストのレビュー

リクエストのレビュー権限を持つユーザーは、図5に示すように、レビューダッシュボードで他のユーザーから提出されたリクエストを承認または拒否することができます。レビュー待ちの各リクエストには、リクエストの情報が表示され、リクエスト送信者によって提供されたビジネス上の正当性も表示されます。

Figure 5: The review dashboard

図5: レビューダッシュボード

レビューアは、リクエストを選択し、そのリクエストが適切かどうかを判断し、承認または拒否のいずれかを選択することができます。

レビュアーがリクエストを承認または拒否すると、アプリケーションは /approve… または /reject… の API エンドポイントを呼び出し、DynamoDB テーブルのリクエストの状態を更新し、通知を開始します。

セッションの起動

要求者は、リクエストが承認されたことを通知された後、アプリケーションにログインし、図6に示すように、承認されたリクエストを確認することができます。そして、承認された各リクエストについて、セッションを呼び出すことができるようになります。セッションを呼び出すには、Access console または CLI の2つの方法を選択することができます。

Access console を選択した場合、ブローカーはAWSマネジメントコンソールにユーザーをフェデレートします。
CLI を選択した場合、ブローカーはAWS Command-Line Interface (AWS CLI)で使用するための一時的な認証情報を提供します。

Figure 6: Invoking sessions

図6: セッションの起動

どちらのオプションも、リクエストで指定された AWS アカウントの IAM ロールを想定したセッションをユーザーに付与します。

ユーザーがセッションを呼び出すと、ブローカーは次のステップを実行します。

ユーザーが Access console または CLI を選択すると、アプリケーションは /federate… API エンドポイントのいずれかを呼び出します。
/federate… API エンドポイントは、Lambda 関数を呼び出し、次の3つのチェックを実行してから処理を開始します。
1. ユーザーが認証されているか？Lambda 関数は、アクセストークンと ID トークンが有効であることを確認し、ID トークンを使用してユーザーの身元を判断します。
2. ユーザーは適格か？Lambda 関数は、ID トークン内のユーザーのグループメンバーシップを検査し、呼び出そうとしている AWS ロールとアカウントの組み合わせに対して、ユーザーが適格であることを確認します。
3. ユーザーは昇格しているか？Lambda 関数は、DynamoDB のテーブルを照会し、このユーザーに対して、呼び出そうとしているロールとアカウントの組み合わせの期間がまだ終了していない承認済みのリクエストがあるかどうかを確認することで、ユーザーが昇格状態であることを確認します。
3つのチェックがすべて成功した場合、Lambda 関数は sts:AssumeRole を呼び出し、リクエストで指定された IAM ロールと AWS アカウントについて、ユーザーの代わりに一時的な資格情報を取得します。
アプリケーションは、一時的な認証情報をユーザーに返します。
ユーザーは、AWS マネジメントコンソールまたは AWS CLI で、リクエストで指定された AWS アカウントの IAM ロールの一時的な認証情報を持つセッションを取得します。

ユーザーはセッションを取得すると、AWS マネジメントコンソールまたは AWS CLI を使用して、ターゲットの AWS 環境で実行する必要があるタスクを完了することができます。

ユーザーが一時的な昇格アクセスを呼び出す際に引き受ける IAM ロールは、この目的専用である必要があります。また、その IAM ロールでは、ブローカーがそのロールを引き受けることを許可する信頼ポリシーを持っていなければなりません。信頼されたプリンシパルは、ブローカーの /federate… API エンドポイントで使用される Lambda 実行ロールになります。これにより、それらのロールを引き受けるには、ブローカーを経由するしかないことが保証されます。

このように、必要な条件が満たされると、ブローカーはユーザーに代わってターゲットの AWS 環境内の要求されたロールを引き受け、その結果得られる一時的な認証情報をユーザーに渡します。デフォルトでは、一時的な認証情報の有効期間は1時間です。ユーザーの昇格アクセス期間中は、必要に応じてブローカーを介して複数のセッションを呼び出すことができます。

セッションの有効期限

AWS マネジメントコンソールや AWS CLI でユーザーのセッションが終了しても、昇格状態が有効であれば、ブローカーに戻り、新しいセッションを呼び出すことができます。

昇格アクセスの終了

ユーザーの昇格アクセスは、リクエストが承認された後、リクエストされた期間が経過した時点で終了します。

Figure 7: Ending elevated access

図7: 昇格アクセスの終了

特定のリクエストに対して昇格アクセスが終了すると、図7に示すように、ユーザーはそのリクエストに対してセッションを呼び出すことができなくなります。さらにアクセスが必要な場合は、新しいリクエストを送信する必要があります。

アクティビティ履歴の表示

図8に示す監査ダッシュボードでは、許可されたユーザーに過去のアクティビティを読み取り専用で表示します。

Figure 8: The audit dashboard

図8: 監査ダッシュボード

セッション活動のログ

ユーザーが一時的な昇格アクセスを呼び出すと、AWS コントロールプレーンでのセッション活動が AWS CloudTrail に記録されます。AWS コントロールプレーンでアクションを実行するたびに、対応する CloudTrail イベントにはユーザーの一意な識別子が含まれ、アクションを実行した人間のユーザーのアイデンティティを追跡するトレーサビリティを提供します。
次の例は、ユーザー someone@example.com が一時的な昇格アクセスを使って実行したアクションの CloudTrail イベントの userIdentity エレメントを示しています。

"userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROACKCEVSQ6C2EXAMPLE:someone@example.com-TempAccessRoleS3Admin",
    "arn": "arn:aws:sts::111122223333:assumed-role/TempAccessRoleS3Admin/someone@example.com-TempAccessRoleS3Admin",
    "accountId": "111122223333",
    "sessionContext": {
        "sessionIssuer": {
            "type": "Role",
            "principalId": "AROACKCEVSQ6C2EXAMPLE",
            "arn": "arn:aws:iam::111122223333:role/TempAccessRoleS3Admin",
            "accountId": "111122223333",
            "userName": "TempAccessRoleS3Admin"
        },
        "webIdFederationData": {},
        "attributes": {
            "mfaAuthenticated": "true",
            "creationDate": "2021-07-02T13:24:06Z"
        }
    }
}

セキュリティに関する注意事項

一時的な昇格アクセスブローカーは、お客様の AWS 環境へのアクセスを制御するものであり、不正アクセスの防止には細心の注意を払う必要があります。また、AWS 環境にアクセスするうえでインライン型の依存関係があるため、十分な耐障害性を持って運用する必要があります。

ブローカーは専用の AWS アカウントにデプロイし、アクセス管理を行うターゲットの AWS 環境との依存関係は最小限にする必要があります。最小特権の原則に従って、ブローカー自体のアクセス制御設定を実施する必要があります。理想的には、ブローカーは専門のチームによって管理され、独自のデプロイメントパイプラインを使用し、変更を行うための2人ルール（例えば、コードのチェックインとデプロイの承認を異なるユーザーに要求する）を採用するべきです。ブローカーのコードと設定の完全性、およびブローカーが扱う一時的な認証情報の機密性を保護するために、特別な注意を払う必要があります。

セキュリティに関するさらなる考慮事項については、リファレンス実装の README を参照してください。

ソリューションの拡張

リファレンス実装を拡張して、組織の要件に適合させることができます。以下は、このソリューションを拡張するいくつかの方法です。

UI をカスタマイズし、組織のブランド名を使用する。
ネットワークセキュリティポリシーに準拠するため、ネットワークトラフィックをプライベートネットワーク内に制限する。
一時的な昇格アクセスの開始と評価のプロセスを変更し、変更管理またはインシデント管理システムと統合する。
アクセス範囲や粒度、または正当性の異なるグループを使用するために、承認モデルを変更する。
ID プロバイダーが OpenID Connect をサポートしていない場合に、SAML 2.0 を使用する。

ソリューションの拡張に関する詳細については、リファレンス実装の README を参照してください。

まとめ

この投稿では、一時的な昇格アクセスを実装することによって、AWS 環境へ人がアクセスすることに伴うリスクをどのように軽減できるのかについて学びました。自動化によってリスクの高い人によるアクセスの必要性を排除し、自動化できない低頻度のアクティビティにのみ一時的な昇格アクセスを使用することを目指すべきであると学びました。最後に、一時的な昇格アクセスのための最小限のリファレンス実装をダウンロードし、組織のニーズに合わせてカスタマイズできることを学びました。

この記事に関するご意見・ご感想は、以下のコメント欄からお寄せください。この投稿について質問がある場合は、AWS IAM フォーラムで新しいスレッドを立ち上げるか、AWS サポートに連絡してください。

翻訳は Security Specialist TAM の飯島卓也が担当しました。原文はこちらです。

Amazon Web Services ブログ