【はじめに】
会社内でクラウドサービスを共用していると、「複数プロジェクトに関わっているメンバーは、プロジェクトごとにリソースのアクセス権を設定したい」、「商用の環境には開発メンバーはアクセスできないようにしたい」といったアクセス権の管理における問題がよく発生します。
その他にも、社内の研修でクラウドを使用するハンズオンをするような場合に、研修の参加者には業務で使用している領域にアクセスできないようにする必要がでてくるケースもあると思います。
今回は、このような課題の対処に活用できる「スイッチロール」という、「AWS Identity and Access Management（以下、IAM）」が提供する機能の活用事例について紹介します。
※なお、本記事では、AWS利用開始時に払い出されるAWSアカウントやルートユーザーについては言及しません。ルートユーザーによるIAMユーザーの作成以降にフォーカスしています。
【AWS IAMによるリソースアクセスの制御】
AWS IAMを活用することで、AWS上にあるリソースへのユーザーのアクセスを制御＝「誰がどのリソースを使用できるかの設定」ができます。この制御をする上で、IAMには、「IAMユーザー」、「IAMグループ」、「IAMロール」、「IAMポリシー」という４つの主要な概念があります。
- IAMユーザー：一般的なサービスでいうアカウント。人ごとにログインで使用する識別情報。
- IAMグループ：同じプロジェクトの参画メンバーや、同じ役割ごとのユーザーをグループ化する。
- IAMポリシー：AWSの各リソース（サービス）にどの操作を許可するか（読み取りだけor編集可など）のルール設定。
- IAMロール：AWSのリソースが他のAWSのリソース（Lambda⇒S3など）の操作を許可するかのルール設定。
これらの機能を組み合わせて、特定のIAMユーザー（特定の社員）だけがある操作が可能とすることや、特定のIAMグループに所属するユーザーの操作を管理することができます。
IAMロールの説明の例にはAWSのサービスを記載しましたが、この対象となる「AWSリソース」には”別のAWSアカウント”も含まれており、IAMのスイッチロール機能はこれを活用します。
【ユーザーごとのロール設定の重要性】
すべての社員に払い出したIAMユーザーが、どのリソースにも自由にアクセスできるような場合、ヒューマンエラー等により以下のようなことが発生する可能性があります。
- 自分の担当プロジェクトのリソースに対して行う変更を、誤って別のプロジェクトのリソースに適用してしまう
- 開発作業用にお試しで作業しようとした内容を、誤って商用の環境に適用してしまった
- テストや学習を目的とした作業で、過剰なリソースの追加や不要な設定をしてしまい、高額な課金が発生する
これらが発生してしまった場合、大きな障害となりサービスを利用しているユーザーに影響してしまう等、会社にとって大きな不利益を生むことは間違いなく、絶対に回避しなくてはいけません。
このような問題が発生しないように、作業を行う1人1人が強く意識すること、作業の運用方式で軽減することはもちろんですが、「ユーザーごとに必要最小限な操作しかできないように」するというシステムでの制約が非常に重要です。この制約をかけるのが、前述したIAM機能の活用で実現できます。
企業で契約しているAWSアカウントに対しては、従業員ごとのIAMユーザー、担当領域を踏まえたIAMグループを作成した上で、担当業務に即したIAMポリシーをIAMユーザー/IAMグループに対して設定することが一般的です。
こうすることで、メンバーごとが責任を持つ領域の明確化、管理/セキュリティの強化にも役立ちます。
【スイッチロールの活用事例】
続いては、実際にIAMを活用するケースについて紹介します。
例えば自社のプロジェクトで、すでに商用で利用開始しているサービスが稼働している本番環境と、今後リリースを予定している追加機能開発を行うための開発環境の、2つの環境を構築しているとします。
このとき、管理業務をするチームと、開発作業を行うチームで操作できるリソースを変更したいような場合、開発作業用と管理作業用のアクセス権を設定したIAMユーザーを開発環境と本番環境のそれぞれで作成することで、実施する作業ごとに必要最低限の権限を付与することが実現できます。
しかし、この場合、社員自身で複数のユーザー情報（ID/ユーザー名/パスワード）を管理し、作業を切り替えるたびにログイン/ログアウトを繰り返すことになります。
こうなってしまうと、関連するプロジェクトが増えたり、使用する環境が増えたりするたびに、IAMユーザーの数が増えていき、作業者もアカウント管理者も管理や運用が煩雑になってしまいます。
この課題を解消するのが、スイッチロールです。
スイッチロールを導入した場合、以下の図の通り、作業者は、1種類のID/ユーザー名/パスワードでログインを行い、そのログイン後にスイッチロールから、利用するロールを選択するだけで切り替えが可能になります。
このように、複数の作業を行うメンバーを管理する上で、スイッチロールはとても有効で便利な機能ですが、切り替えがしやすいということは、逆に誤ったロールの切り替えが起こりやすくなることにもつながります。
そのため、スイッチロールを活用する際には、「ロール名の命名をわかりやすくする」ことが重要です。作業者がロールを選択する際に、環境や対象とするプロジェクト等がわかりやすい名称としておくことで、こういった誤りを防止することにつながります。
また、Microsoft EdgeやGoogle Chromeのブラウザ拡張機能として提供されている「AWS Extend Switch Roles」の活用もおすすめです。AWSのコンソールからのスイッチロールを拡張するもので、ロールごとに色設定をすることもできるようになります。
「AWS Extend Switch Roles」は、管理者での設定ではなく作業者側での導入になるので、利用手順として設定方法を展開する等の取り組みをするとよいです。
【スイッチロールの設定の仕方】
■スイッチロールの設定
- スイッチ先のAWS環境で、IAMロールを作成し、スイッチ元のアカウントIDを指定します。
- IAMロールに対して必要なアクセス権限（ポリシー）を付与して、必要最小限な権限設定を構築します。
■既存の環境にスイッチロールの機能を追加したい場合は？
スイッチロールの設定がされていない環境に、追加でこの機能を導入したい場合は、以下の手順で設定することが可能です。
- スイッチ先AWS環境にIAMロールを作成します。
※ロールの信頼関係にスイッチ元AWSの情報設定が必要です。 - スイッチ元AWS環境に項番1で作成したロールを使用する権限をIAMユーザーやIAMグループに対して付与します。
- 利用者にAWSアカウントIDおよびスイッチのロール名を伝えます。
【環境自体の使い分け】
上記の通り、スイッチロールは切り替えのしやすさや複数ユーザーの管理という観点で非常に有効ですが、作業環境の切り替えをあえて実施しにくくすることで、作業している環境を明示的に意識させることもできます。
「環境ごとにAWSアカウント自体を分離する」や「環境ごとにIAMユーザーをわける」を実施した上で、スイッチロールの設定を行わないことで、明示的に作業時にログイン操作をさせることができます。それぞれの環境利用状況や利用メンバーの人数等を踏まえて導入を検討するのがいいでしょう。
【さいごに】
当社では、今回紹介したスイッチロールも活用し、開発時のセキュリティ遵守/リスクの最小化を考慮して、クラウドを用いた開発を行っている多数の実績があります。
クラウドを活用したサービスの構築を検討している際にはもちろん、新しいサービス開発を検討したいがクラウドの活用ができるかといった際にも、ぜひ当社にご相談ください。
オートモーティブ事業部 第３システム部
今野 和彦
※本ページに記載されている製品名、サービス名、会社名などは、それぞれの企業の登録商標または商標です。
【公式X（旧Twitter）】
X（旧Twitter）でシェア