AWS アクセス管理を一歩先へ！カミナシのセキュアな AWS アクセス管理を実現するシステムの紹介

カミナシのエンジニアリング組織では、チームメンバーの AWS アカウント環境への定常的なアクセス権限として「センシティブな情報を除いた全リソースへの ReadOnly Access」を付与しており、一方で書き込み権限については必要に応じてメンバーが一時的に権限を獲得できる仕組みとシステムを開発し、運用を行っています。

本記事では、そういった仕組みを開発するに至った経緯や仕様、そしてこれを数ヶ月ほど運用した結果と今後の展望について紹介します。

このシステムは『ハマヤン』という名前で呼ばれていますが、あまねくユーザーに愛される素敵な名称であり、Sec Eng チーム内でも大人気です。開発者が濱野さんだからハマヤンにしたのでは？と社内で言われることがありますが、真相は不明です。

ハマヤンを開発した理由

ハマヤン開発前の2022年頃、カミナシではソフトウェアエンジニア全員が Administrator Access を使用して AWS アカウント群へアクセスし、いつ事故が起きてもおかしくない状態でした。こういった状況は好ましくないと弊社 CTO 原トリがカミナシ入社後6日目にして、この如何ともしがたい状況を打破するために5,000文字を超える AWS アクセス権限管理発行ガイドラインを書きあげました。これが、その後の GitHub でのコード管理による IAM Identity Center への移行や IAM User の全廃を経て、後のハマヤンにつながっていきます。

ハマヤン開発の目的はカミナシ社員あるいは業務委託メンバーに代表されるシステム開発と運用のステークホルダに AWS アカウント群へのアクセス権限を提供するにあたり、以下としました。

その業務遂行に必要と認められる範囲の権限が
必要なタイミングで
適切な業務遂行者に対して
必要と認められる期間に限り提供される状態を作る

合わせてアクセス権限の要求と提供の履歴を適切に保持し、管理運用していくこともそのゴールとして設定されていました。

ハマヤンの開発で気をつけたこと

ハマヤンを開発する上で気を付けたこととして、「必要な権限取得のプロセスを極力シンプルにすること」があります。カミナシではソフトウェアエンジニアがプロダクトに対してオーナーシップを持つことを重要視しています。オーナーシップを持つためには何かプロダクトに異常が発生した際に即座に確認したり、適切な対応ができる状態になっている必要があります。
これらを可能とするために AWS アカウントへの権限が必要となるのですが、その権限取得のプロセスが複雑だったりリードタイムが長いとオーナーシップを奪いかねません。そのため、ハマヤンでは権限取得のプロセスを極力シンプルにすることを念頭に開発しました。具体的な権限取得プロセスは下部に記載している「ハマヤン利用イメージ」をご確認ください。

ハマヤン利用シーン

カミナシでは IAM User を利用せず、IAM Identity Center を利用する運用としています。開発者は常時読み取り権限(一部特定リソースへの書き込み権限も含む)が付与されており、その権限を利用して普段の開発/運用を行なっています。AWS 環境のリソースは IaC 化されているため読み取り権限のみあれば基本的に事足りるのですが、障害調査やその対応で一時的に強いアクセス権限が必要になる場合があります。そういった場合に開発者はハマヤンを利用して短時間の特権アクセスを取得します。

ハマヤン利用イメージ

実際にどのようにハマヤンを利用して IAM Identity Center の一時アクセス権限を取得するのか紹介します。

ハマヤンは Slack App として提供しています。利用者は特定の Slack チャンネルで Slack スラッシュコマンドを実行してハマヤンを起動させます。起動後 Slack モーダルが表示されるため必要事項を選択、記入して実行します。

実行後 Slack チャンネルに記入内容が送信され、一時アクセス権限が付与されるとスレッドに返信がきます。

この状態で IAM Identity Center のログイン画面を確認するとアクセス権限が付与されています。利用者はこの権限を利用して障害調査やその対応を行います。

そして、ハマヤン実行時に指定した有効時間が過ぎると付与された権限が削除され、失効メッセージがスレッドに返信されます。

ハマヤンのアーキテクチャ

以下はハマヤンの構成図です。

Slack App のバックエンドに Lambda を利用し、Slack App からのスラッシュコマンド処理、モーダル表示、モーダル入力内容のバリデーションチェック等を行なっています。そしてモーダル入力内容を input として StepFunctions を起動させます。 StepFunctions のワークフローとしてはシンプルに以下のような流れになっています。

アクセス権限付与のため IAM Identity Center の CreateAccountAssignment API を Lambda にて実行
権限有効時間まで処理を wait
アクセス権限削除のため IAM Identity Center の DeleteAccountAssignment API を Lambda にて実行

特筆する点としては、IAM Identity Center の API を実行できるアカウントが限られているという制約があることです。
IAM Identity Center の API を実行できるのは AWS Organizations の管理アカウント、もしくは IAM Identity Center の管理機能を委任されたアカウントのみという制約があります。しかし、紹介したこれらの Lambda はハマヤン用に用意したアカウント上で稼働しています。そのため、Lambda から IAM Identity Center の API を実行するために IAM Identity Center の API を実行できるアカウントに用意した IAM Role に Assume Role しています。

また、ハマヤンで利用している AWS リソースは Terraform で IaC 化しており、Lambda コードの実装には Go を採用しています。

Temporary elevated access management (TEAM) との棲み分け

ここまでハマヤンの説明を聞いてピンときた方もいるかと思いますが、実は同じような IAM Identity Center の一時アクセス権限を発行するオープンソースソリューションとして Temporary elevated access management (TEAM) が AWS から公開されています。
カミナシでも TEAM の採用を検討しましたが、以下の理由で採用は見送りました。

TEAM が公開されたタイミングでは既にハマヤンの社内 PoC が完了しており、十分に業務が回ることが分かっていた
現在のカミナシのシステム運用レベルやニーズに対しては TEAM は機能過多であった
TEAM はその機能の豊富さから、動作に必要なシステムコンポーネントもハマヤンと比較して複雑であり、デプロイした TEAM の AWS リソースや実装コードを少人数で構成される Sec Eng チームが運用・メンテナンスしていくには想定される負荷が高かった

将来的にカミナシでの運用ニーズが変わったり、はたまたソリューションではなくフルマネージドなサービスとして一時アクセス権限の取得が可能になればハマヤンからの移行も十分に検討の余地があると思っています (AWS さん、マネージドなソリューションの提供をお待ちしております・・・！)。