受託ビジネスにおいて、特に考える必要のあるセキュリティへの考慮
工数削減以上に重要な点として、システムやインフラ環境に対するセキュリティ対策があります。
受託ビジネスでAWSを利用すると、主に顧客単位でアカウントを管理する必要があります。個々のシステムに関するセキュリティについては、それぞれのプロジェクトで考慮をする内容ですので、本稿では言及しません。
AWSを利用する際の契約的なスキームとしては以下のケースがあります。
- 顧客や他ベンダーがAWSのアカウントを有しており、そのアカウント上でサービスを稼働させる
- 開発ベンダーがAWSアカウントを所有し、そのアカウントの運用保守契約を提携した上で、サービスを稼働させる
1.の場合はアカウント取得側でユーザ管理を実施する／しないはケースバイケースですが、2.のようにAWSの運用を含めた業務を実施する場合、AWSを利用するユーザ（開発者、運用者）をアカウント毎に管理する必要があり、顧客数（N）、ユーザ数（M）に対してO（N×M）のオーダーのユーザー数を管理する必要があります。
AWSアカウントにユーザを追加する場合、通常は開発者、運用者毎にIAMユーザを作成することが多いですが、O（N×M）ですので、AWSアカウントが多くなるとすぐに管理工数が大きくなります。
例えば、20のAWSアカウントを管理しており、各アカウントに5名分のユーザを登録する場合、100IAMユーザを管理する必要があります。また、100IAMユーザの中には実態（人）が重複することが多々あり、一人の人に対する変更をする場合、最大O（N）のユーザの変更をする必要があります。
また、ユーザ数が多くなることによる管理工数の増大以外にも。以下の問題点があります。
- プロジェクトに対するアサインが変更した場合のユーザ登録削除の手間がかかる。
- ユーザが放置された場合にセキュリティリスクがある
- ユーザ毎に発行されたアクセスキーID／シークレットアクセスキー[*]が実際のサービスに組み込んでしまうケースがある（ユーザを削除するとサービスへアクセスできなくなる）。
[*] アクセスキー／シークレットアクセスキーについて
AWS SDK、REST、またはクエリAPIオペレーションを使用している場合、プログラムによるAWSへのリクエストに署名するにはアクセスキーを使用します。
AWSアカウント内のユーザ管理にはさまざまな方法がありますが、受託ビジネスのような顧客数（N）が大きくなり、N×Mのユーザの中で実施の人が重複することが多いケースでは、「SAML 2.0ベースのフェデレーション」が有効です。
詳細は、本連載の中で解説していきますが、「SAML2.0ベースのフェデレーション」によって以下のようなことが実現できるようになります。
- 紐づけられたIAMロールの権限を持つフェデレーテッドユーザとして、AWSマネージメントコンソールにログインする。
- ユーザはIdP（Identiry provider、Active Directory／Active Directory Federation Serviceなど）で管理する。
- ユーザはグループに所属させ、グループとAWSアカウント（+IAMロール）を紐付ける。
- AWSはIdPを信頼し、IdPで認証、認可されたユーザをSTSによりIAMロールと紐付ける。
結果として以下のメリットが享受できます。
- AWSにログインするユーザをActive Directoryで一元管理することができる。
- 任意のAWSアカウントとIAMロールをActive Directory内で紐づけできるようになる。
- IdPのセキュリティを強化できる。
- アクセスキーID／シークレットアクセスキーがサービスに埋め込まれる心配が低減する。
最後に
本稿では、比較的小規模なフルスクラッチの業務システムをビジネスとし、開発を実施する際に参考となるAWSのアーキテクチャや工数のかかる工程、留意すべきセキュリティに関するポイントを解説しました。
次稿以降で、以下について具体的な実践方法を含めて解説していきます。
- Ansible／Vagrant／Packerを用いた開発環境、本番／ステージング環境の構築例
- SAML 2.0ベースのAWSマネージメントコンソールへのフェデレーション（シングルサインオン（SSO））
- とはいえ、新しい技術動向を取り入れたい。受託業務におけるサーバレス活用例
