安全で自由度の高いAWS Sandbox環境の作り方

はじめに

金融機関を含む様々な業界でAWSの利用が進み、安全なクラウド使用が広がっています。しかし、クラウドを利用する開発者からは、以下のようなニーズや課題が挙げられることがあります。

• AWSの新サービスを手軽に試したいが、環境を設定するまでに時間がかかる。
• 現在の開発環境でIAM権限が制限されており、試したい機能にアクセスできない。
• IAM権限の精査を安全に行いたいが、適切な環境がない。
• プロダクション環境に影響無く、プロトタイプやインフラのテストを実施したい。
• AWSを学習するための環境が欲しい。(個人アカウントを利用してしまっている)

このような時、解決策としてAWS Sandbox環境が役立ちますが、その構築は必ずしも簡単ではありません。この環境を設計する際には、アクセス制御、コスト管理、セキュリティポリシーの遵守、および使用後のリソースの削除といった要素が重要な考慮事項です。また、企業が定める情報セキュリティポリシーに準拠しながらこれらを実現することは、一定の難易度を伴うと感じております。本ブログでは、実際にSandbox環境の構築検討した具体的な事例を交えつつ、これらの要素を効率的に管理し、Sandboxを有効に活用する方法を紹介します。効果的なSandbox環境は、開発の自由度を高め、イノベーションの促進に貢献しますので、お役立ていただければ幸いです。

1.Sandbox環境サービス内容検討のアプローチ（AWSのWorking Backwards）

まず、Sandbox環境のサービス内容を検討する際、Amazonの「Working Backwards」アプローチが有効なので紹介します。「Working Backwards」アプローチは、製品やサービスの開発過程で顧客中心の思考を促進する手法です。このプロセスでは、Amazonがサービスを市場投入する前にプレスリリース（PR）とよくある質問（FAQ）を作成し、開発チームが顧客のニーズと製品の最終目標を明確に理解するのを助けます。Sandbox環境の設計にあたり、利用者の視点を重視するためこの手法を適用します。

以下は、PR/FAQドキュメントを作成する際に含めるべき主要な項目です。

参考にSandbox環境のプレスリリース(PR)の簡単な例を記載します。

Sandbox環境の構築に際し、その予算確保や目的を社内や経営層に説明する際には、利用者の視点を中心に設計し整理することが重要です。この目的を達成するために、「Working Backwards」プロセスを採用することは有効な手法です。また、このアプローチにより、Sandbox環境を提供する開発チームはプロジェクトの初期段階から利用者のニーズを深く理解し、そのニーズに基づいてサービスを設計することが可能になります。

※参考：Read an excerpt from "WORKING BACKWARDS: Insights, Stories, and Secrets from Inside Amazon" by former Amazon employees Colin Bryar and Bill Carr
https://www.aboutamazon.com/news/workplace/an-insider-look-at-amazons-culture-and-processes

2.Sandbox環境のセキュリティについて

前述したように、企業が設定した情報セキュリティポリシーに準拠しつつ、利用者に一定の自由度を提供し迅速に環境を提供することは一定の難易度が伴います。Sandbox環境で利用者に広範な権限を与えて自由度を高めたいものの、セキュリティと自由度はしばしばトレードオフの関係にあります。ここからは、これらのジレンマに対しどのようなアプローチを取り入れたのかを記載します。

(1) 情報セキュリティについて

Sandbox環境におけるセキュリティ対策を検討するにあたり、まず「情報セキュリティ」の基本について解説します。情報セキュリティは、リスクベースのアプローチが鍵となります。具体的には、情報資産、それに対する脅威、および脆弱性の三要素の価値や影響度を評価し、そこからリスクを特定します。これらの要素のいずれかを減少させることで、リスク軽減が可能です。（例：保護すべき情報資産がなければ、情報漏洩のリスクはなくなります）
多くのSandbox環境では本番データを扱わないため、情報漏洩のリスクが低く、過度なセキュリティ対策を避けることができます。セキュリティ部門に説明する際も、リスクベースでのアプローチを通じて行うことが重要です。

▼情報セキュリティのリスク評価

(2) クラウドセキュリティ対策の基本

クラウドセキュリティを強化するための基本的な対策には、以下の5つがあります。今回のSandbox環境においては、確実にInternal環境であることを制御します。またアクセスコントロールと認証、データの暗号化は適切に行うことが重要です。さらに、Guardrailの概念を採用して、予防的統制と発見的統制を組み合わせ、これらの対策を多層防御で設計します。

Sandbox環境ではその利用特性から開発の自由度をなるべく高め、必要なセキュリティ対策を効率的に行う必要があります。また、Guardrailについても、新サービスのPoC利用などを素早く試せるようにある程度自由度が必要なため、予防的統制ではなく追跡性の確保を重視し発見的統制を重要視します。

3.Sandbox環境の実装例

続いて、安全かつ高い自由度を持つSandbox環境の実装例についてご紹介していきます。
この実装例では、以下の前提条件を設定することとし、4つのポイントについて解説します。

(1) AWS OrganizationsとAWS Control Towerを使用したGuardrailsガイドラインの適用

AWS Sandbox環境の構築において、AWS OrganizationsとAWS Control Towerを使用することで、セキュリティと統制を向上させることが可能です。この方法では、Sandbox環境をはじめとするAWSリソースに一貫したポリシーを適用し、セキュリティを管理します。さらに、各利用システムの環境とコストを分離するために、マルチアカウント戦略を採用します。

▼AWS OrganizationsとAWS Control Towerを活用したSandbox環境例

①AWS Organizationsの役割

AWS Organizationsは、AWSアカウントの集中管理を可能にするサービスであり、複数のAWSアカウントを階層的に管理し、組織全体に共通のポリシーを適用できます。このサービスを利用することで、Sandbox環境を含むさまざまな環境で、特定のAWSサービスの利用制限やIAMロールの一貫した管理など、企業ポリシーに沿った運用が可能になります。

例えば、Service Control Policy（SCP）機能を使い、セキュリティ上好ましくない操作^（※1）の禁止や、利用可能リージョンや意図せず高価になりがちなAWSサービスやEC2インスタンスタイプの使用制限など、アカウント全体に対する統制を強化し、予防的なGuardrailを容易に実装できます。
また、AWS Organizationsを利用することで、アカウントの作成や閉鎖が簡単になり、アカウントを閉鎖することで、そのアカウント内の不要なリソースを一括で削除することができます。

※1 SCPの設定例
・Control Towerによって設定されたGuardrailに関連するリソース（SNS、通知用のAWS Lambda、AWS CloudTrail、AWS Config、ログ保管用のAmazon S3、SecurityHubなど）の設定変更を禁止
・内部環境を維持するため、Internet Gatewayの作成を禁止
・アカウントレベルで設定されたS3パブリックアクセスブロック設定変更を禁止
・AWS IAMのアクセスキーの作成を禁止

②AWS Control TowerとGuardrailsの導入

AWS Control Towerは、AWS環境のセットアップとガバナンスを自動化するサービスで、Guardrailsと呼ばれるガイドラインを提供します。これらのGuardrailsには、セキュリティ、運用、コンプライアンスのベストプラクティスが含まれており、自動的にポリシー違反を検出し、必要に応じて修正を行うことができます。Sandbox環境においても、Control Towerを利用することで、予防的なセキュリティ対策やリアルタイムの監視を行い、安全な開発環境を保持できます。
本ブログでは詳細な説明は割愛しますが、Sandbox環境において有効な機能について以下記載します。

- Guardrailsの適用

Guardrailsは、強制的（Mandatory）、強く推奨（Strongly recommended）、選択的（Elective）の3種類に分類されます。Sandbox環境では、これらのGuardrailsを適用することで、不要なサービスの使用を防ぎ、IAMポリシーに基づいた細かいアクセス制御を行うことができます。また、データの暗号化やログの監視など、セキュリティ対策を自動化し、運用の負担を軽減します。

- 通知の強化

AWS Configを利用して、AWSリソースの変更情報やAWS Configルールの準拠状況をAmazon SNSを通じて通知することができます。AWS Configには豊富なマネージドルールが提供されており、AWSの知見に基づいたベストプラクティスの設定が可能です。さらに、通知に必要なSNSやAWS Lambdaなどのリソースは、AWS CloudFormationのStackSetsを使用して全アカウントにわたって一貫した設定を配布できます。

- プロアクティブコントロール

AWS Contorol Towerのプロアクティブコントロールは、AWS CloudFormationテンプレートがリソースをプロビジョニングする前に、AWS CloudFormation Guardルールを使用してリソースを事前にスキャンする機能です。もしルール違反が検出された場合、AWS CloudFormationのフックによってプロビジョニングは中断されます。このプロセスにより、未来のセキュリティリスクを事前に防ぐことが可能となり、利用者がより安全に環境を構築できるようになります。本機能は、セキュリティと統制を強化し、Sandbox環境に限らず本番環境でも利用者自身でプロビジョニングをより安全に行うための可能性を秘めています。そのため、筆者はこの機能に特に期待を寄せています。

※参考：プロアクティブコントロール
https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/proactive-controls.html

- その他のセキュリティガバナンス対策

AWS Control Towerと併用してセキュリティガバナンスを強化するための重要な設定やサービスを以下に示します。これらのサービスは、AWS Control Towerと組み合わせることで、AWS環境のセキュリティとコンプライアンスの管理を効果的に行うことができます。

(2) 利用者によるコスト管理の徹底

Sandbox環境では、利用者が自らコストを効率的に管理できるようサポートするサービスの利用が重要です。不意のコスト増加を防ぐために、以下のサービスを利用します。これらのツールを活用することで、Sandbox環境の利用者はコストを積極的に管理し、予算内での運用を確実に行うことができます。

※参考：AWS Budgets を用いてコストを管理する
https://docs.aws.amazon.com/ja_jp/cost-management/latest/userguide/budgets-managing-costs.html
※参考：AWS 異常検出で異常な使用料を検出する
https://docs.aws.amazon.com/ja_jp/cost-management/latest/userguide/manage-ad.html

(3) AWS IAM Identity Centerを利用したSSOとABACによるアクセスコントロールの強化

マルチアカウント戦略のもとで、AWS Control TowerとAWS IAM Identity Centerを用いてマルチアカウント環境におけるシングルサインオン（SSO）を実現します。加えて、ABAC（Attribute-Based Access Control）の採用により、ユーザの属性に基づいたアクセス制御を実施し、より精密な管理と柔軟な制御を実現します。これにより、IAMやKMSなど、従来セキュリティ設計上の制約で利用者へ権限の提供が難しかったリソースについても、必要最小限の権限の原則に基づき、特定のユーザへ安全に提供することが可能になります。これは、自由度とセキュリティの両立を促進します。ABACの導入は、企業内のセキュリティポリシーに準じて、必要に応じて検討することが推奨されます。

※参考：AWSのABACとは
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/introduction_attribute-based-access-control.html

①AWS IAM Identity Centerを利用したSSO環境

以下にAWS IAM Identity Center利用したSSO環境の例を記載します。またABACを適用し組織内でも特定の属性を持つユーザにIAMとKMSサービスが利用できる権限を付与した例です。

▼AWS IAM Identity Centerを利用したSSO環境の例

②フェデレーションでユーザを識別してアクセス制御する方法（参考）

ABACを適用するには企業内ディレクトリの属性情報を利用しますが、Sandbox環境用に新たに企業内ディレクトリに属性を追加したり、柔軟な運用が難しい場合があるかと思います。以下例ではフェデレーションのユーザをロール側で識別しIAM、KMSサービスへの権限を付与した例です。IAMポリシー側の設定で容易に実現できるため、少し力技ですが小規模環境やスモールスタート向けの参考に記載します。

▼フェデレーションでユーザを識別するポリシー例

本章で述べた通り、一定の自由度と安全性を兼ね備えたSandbox環境を提供するためには、AWS Control TowerのGuardrailsやAWS Configのマネージドルールなど、AWSの知見に基づくベストプラクティスの適用が重要です。特にSandbox環境では、新しいサービスの試験などを行うため、管理者が都度セキュリティの設計を行うのは困難です。また仕組みを作り込んだ結果、サービスが硬直化して本来のSandbox環境の目的が薄れてしまう危険もると考えます。セキュリティの鍵は再利用にありますので、これらのサービスを利用して、効率的な管理を実装しましょう。

(4) AWS Innovation Sandboxソリューションを活用したSandbox分離環境

これまで記載してきた実装例は、一定の統制の下でSandbox環境を利用することを前提としています。しかし、より自由に使いたい、さまざまなことを試したいというニーズが存在場合もあると思います。このような場合は、以下の前提に基づいてリスクを低減しつつ、自由度の高いSandbox環境を提供することが可能です。Sandbox環境といえば本例をイメージされる場合もあると思います。利用者のニーズに応じて上述してきた実装例と組み合わせて以下環境を提供します。

• AWS Innovation Sandboxソリューションを利用して独立して安全なSandbox環境をデプロイします。
• ブラウザベースのアクセスに Amazon AppStream 2.0を利用し、ローカルネットワークから意図しないデータやファイル転送を防ぐセキュリティを実装します。
• AppStream2.0へのアクセスはAWS IAM Identity Centerを利用したSSOを構成し、企業内ディレクトリと連携したアクセス制御として外部からのアクセスを不可とします。

※引用：AWS Innovation Sandbox
https://aws.amazon.com/jp/solutions/implementations/aws-innovation-sandbox/

4.まとめ

• Amazonの「Working Backwards」アプローチ等を採用し、Sandbox環境の利用者のニーズを深く理解し、それを社内や開発チーム、利用者と共有して進めます。
• 企業が設定した情報セキュリティポリシーに準拠しつつSandbox環境を構築するには、自由度とセキュリティがトレードオフの関係にあるため、リスクベースでアプローチし、過度なセキュリティ対策を避ける方向で検討します。
• Sandbox環境の構築には、AWS Organizations、AWS Control Towerや各種セキュリティガバナンスサービスを活用し、AWSベストプラクティスに基づくSandbox環境向けのガードレールを設計し、自由度の高い安全な環境を目指します。
• 必要に応じてABAC（Attribute-Based Access Control）を採用し、より精密なアクセスコントロールを通じてより高い自由度の権限付与を可能にします。
• AWS Innovation Sandboxソリューションを利用したSandbox分離環境を通じて、さらに高い自由度と安全性を兼ね備えた環境の構築が可能です。

5.最後に　～Sandbox環境を今後より活用するには～

ビジネス環境の変化やテクノロジーの進化に伴い、開発プロセスのスピードとライフサイクルが更に加速していくことが予想されます。この環境下では、Sandbox環境の利用者に今後CI/CDの仕組みを提供し、コードベースでAWSリソースを含めた環境デプロイが可能な基盤の構築が必要と考えます。成長を持続可能とするには、さまざまな機能を試行できエラーやポリシー違反に迅速に対応し、短いスパンでリリースできる柔軟な基盤を提供していくことが必要です。
また、そのためにPolicy as Codeや承認フローを整備することで、統制とセキュリティチェックを維持しつつSandbox環境を自由に構築でき、その目的である開発の自由度を高め、イノベーションの促進に更に貢献できると考えます。このような仕組みは本番環境にも適用可能であり、AWSのさらなる活用を促進するでしょう。本ブログが皆様の何かの一助になれば幸いです。

著：TIS株式会社
IT基盤技術事業本部 IT基盤技術事業部
IT基盤エンジニアリング第3部 エキスパート
宇井 真