AWS Sandbox環境で新サービス利用を安全に素早く始める方法

はじめに

前回のブログ「安全で自由度の高いAWS Sandbox環境の作り方」では、AWS Organizations、Control Towerや各種セキュリティガバナンスサービスを活用し、AWSベストプラクティスに基づくSandbox環境向けのガードレールを設計し、自由度の高い安全な環境を目指すことについて解説させて頂きました。

※参考：安全で自由度の高いAWS Sandbox環境の作り方：https://www.tis.jp/special/platform_knowledge/cloud34/

しかしながら、金融機関などの企業が定める情報セキュリティポリシーに従いながら、利便性の高いSandbox環境を設計することは一定の難易度が伴います。これは、本番環境向けに既に設定されたルールをそのまま適用すると、Sandbox環境の利便性が損なわれることがあるためです。特に、AWSの新サービスをSandbox環境で手軽に素早く試したいというニーズに対して、企業のセキュリティポリシーに準拠しつつ、安全かつ迅速に環境を提供することがチャレンジとなる場合があります。本ブログでは、Sandbox環境で新サービスを迅速かつ安全に始めるための具体的な事例を交え、その方法について解説します。

１.Sandbox環境でAWSの新サービスを利用する場合の課題

Sandbox環境でAWSから次々リリースされる新サービスや機能を手軽に試せる環境を提供し利用者でクラウドの利活用が促進されるのはSandbox環境の重要な目的のひとつかと思います。ただし、情報セキュリティ部門からは以下のような要件を満たすよう対策を求められる場合があるのではないでしょうか。

• リスクとなる権限がないようIAMの権限評価を行うこと

AWSのIAM（Identity and Access Management）とは、AWSの各リソースへのアクセス権限を管理するためのサービスです。IAMを使用すると、ユーザやグループがどのAWSリソースにアクセスできるかを制御でき、セキュリティを向上させることができます。また、クラウドセキュリティのガードレールや予防的統制も基本的にはIAMを利用して実装します。
リスクとは情報漏洩リスクのことで、IAMのアクセス権限（操作権限）によっては1つの操作で企業の外部へ情報を持ち出せてしまうようなことが対象となります。

Sandbox環境では、さまざまなセキュリティ対策が施され、本番データを扱わないためリスクが低減されています。しかし、企業独自のセキュリティポリシーやルールに従い、バックドアとなる権限を防ぐために、Sandbox環境でも最低限の権限評価が必要となる場合があります。特に、AWSの新サービスを対象とする場合、そのサービスに対する知見が企業内に不足している状況で、迅速にIAMの権限評価を行う方法が課題となります。

２.AWSの新サービス利用を安全に素早くはじめる方法

情報セキュリティ部門の要求に対し、筆者の考える対策は以下3つあると考えています。

• Sandbox環境向けIAMチェックリストを作成し利用部門と管理部門で協力して対応する
• Sanbox環境の利用部門で責任もってIAM評価と管理を行う
• AWS Innovation Sandboxソリューションを活用したSandbox分離環境の提供

本ブログでは1つ目のIAM評価チェックリスト作成ノウハウを重点に解説するため次章で詳しく記載します。先に下2つの対策内容について補足します。

(1)Sandbox環境の利用部門で責任もってIAM評価と管理を行う

Sandbox環境を利用するユーザには主に2つのペルソナがあると考えます。1つはAWSの利用がはじめてでSandbox環境で色々試しながら知見を溜めたいユーザです。またもう一方は、既にAWS環境で開発経験もあり、各AWSサービスの特性やIAMのAction(権限)も設計できるユーザです。

前者のユーザーの場合、AWSのサービスによってはIAM評価を実施することが難しいかもしれませんが、失敗を繰り返しながらクラウドのセキュリティに関するリテラシーを向上させることが可能です。そのため、一定の効果が期待できます。
また、後者のユーザーは、利用部門内で責任を持ってIAM評価や管理を行うことが可能ですが、AWS Control Towerなどを利用してセキュリティガバナンスの仕組みを管理部門側で適用する必要があります。いずれにしても、各利用部門が責任を持って学習していくことが前提となるため、初期段階ではIAM評価の有効性が不透明であり、このパターンをすぐに運用に導入することが難しい場合があります。

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

冒頭で紹介したブログ「安全で自由度の高いAWS Sandbox環境の作り方」にも記載しましたが、より自由に新しいAWSサービスを安全に試したい場合には、AWS Innovation Sandboxソリューションを活用したSandbox分離環境の提供が有効です。この環境は企業内ネットワークと接続しないことを前提としているため情報漏洩のリスクが低く、IAM評価も不要で提供可能と考えられます。ただし、この方法は企業内ネットワークと接続しないユースケースにのみ有効な手段となります。

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

※参考：AWS Innovation Sandbox：https://docs.aws.amazon.com/architecture-diagrams/latest/aws-innovation-sandbox/aws-innovation-sandbox.html

３. IAM権限評価チェックリスト

AWSの新サービスについて知見がない状況で、迅速にIAM評価を行うにはどうすれば良いのでしょうか。また、AWSのセキュリティを管理する部門だけで評価を行うと、管理部門に負荷が集中し、対応スピードが低下する可能性が懸念されます。そのため、IAM評価の経験が少ない利用部門でも評価を実施する必要があるかもしれません。
そこで、これまでに多くのIAM権限設計を対応してきたノウハウをIAM評価チェックリストに整理し、誰でも一定のレベルで実施できるようにまとめました。

(1)IAM権限評価チェックリストの項目

筆者は次のステップでIAMの権限評価を実施する必要があると考えます。

• AWSサービスの特性を把握する
• IAM Action評価を実施する
• 情報漏洩リスクのあるActionについて対策を講じる

(2) AWSサービスの特性を把握する

対象のAWSサービスの特性をまず把握することが重要です。AWSは様々な種類のサービスを提供しており、ユーザーデータを保持するサービスなのか、VPC内に配置可能なのかといったポイントを把握することで、そのAWSサービスの情報漏洩リスクの特性を認識し、対策を講じやすくなります。（IAM評価の有識者は頭の中で自然とこの作業を実施しています）
また、AWSが提唱する責任共有モデルのように、クラウドセキュリティの基本はアクセスコントロール（ACL）と暗号化を適切に利用者が設定することです。したがって、ACLと暗号化を軸に、以下6つの項目についてYes/Noを調べることでサービスの特性を把握します。
※参考：責任共有モデル：https://aws.amazon.com/jp/compliance/shared-responsibility-model/

ネットワークとインバウンド/アウトバウンド制御

※参考①：アイデンティティベースポリシー、リソースベースポリシーとは：https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_identity-vs-resource.html
※参考②：IAMと連携するAWSのサービス（リソースベースポリシー利用可否）：https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html
※参考③：AWSのサービスと統合するAWS PrivateLink：https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/aws-services-privatelink-support.html

アクセスコントロールには2つの観点があると筆者は考えています。1つ目はネットワーク経路におけるACL、2つ目はAWSサービス間の連携におけるACLです。AWSサービス間の連携の例としては、S3レプリケーションのようにネットワーク経路を介さなくても、AWSサービス間で他のAWSアカウントのサービスとデータを連携できる機能があります。これはクラウドの特徴として便利ですが、注意が必要です。

〇VPC内に配置するサービス

VPC内に配置するサービスは、多くの場合そのサービスへのアクセスはネットワーク経路を通じたアクセスとなるため、この時点ではネットワークがインターネットなど外部に接続できないことを中心に確認します。AWSサービス間の連携は次のIAM Action評価で外部アカウントと連携できる機能や操作がないか確認します。

例：EC2サービス

〇VPC外に配置するサービス

VPC外に配置するサービスについては、もう少し詳細を確認します。
以下の図のS3はVPC外に配置されますが、ネットワークの観点では、S3が外部インターネットに直接公開されないように確認します。また、VPC内のEC2からはVPCエンドポイントを経由して内部接続ができることが望ましいでしょう。サービス間の連携としては、例えば外部のS3とのレプリケーションが可能ですが、リソースベースポリシーを使用してS3へのアクセス元を特定のVPCに限定することで、意図しないアクセス元からのアクセスを拒否することができます。（S3の場合、パブリックアクセスブロックなど他にも様々な有効な対策がありますが、ここでは省略します）

例：S3サービス

暗号化と監査ログ

※参考④：AWS サービスでの AWS KMS 暗号化の使用： https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/service-integration.html
※参考⑤：AWSサービストピック CloudTrail：
https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html

ユーザデータを保持するかどうかはデータの有無で情報漏洩リスクが異なること、またデータの保護には暗号化が有効な対策となるため予め機能が提供されているか確認します。また監査ログは不正操作などセキュリティインシデントが発生したときの証跡となるためそのAWSサービスが対応しているか念のため確認します。

(3) IAM Action評価を実施する

アクセスコントロールの重要性について説明しましたが、IAMでは管理者や利用者がAWSサービスに対してどのような操作権限を持つかを設定します。最小権限の原則に従い、必要な権限のみを付与することが望ましいですが、検証段階で必要な権限に絞ることは現実的には困難です。そのため、Sandbox環境では「リスクとなる権限がないことを確認し、適切な対策を講じる」ことに重点を置きます。

次に実施手順について記載します。

①IAM Actionの全量を確認
AWS公式ドキュメントのService Authorization Referenceを参照し、評価対象のAWSサービスのActionを確認します。以下EC2の記載例ですが、ActionsとAccess Levelは必須で、説明はActionの内容を把握するため記載したほうが良いでしょう。情報漏洩リスクと対策は次に説明します。

※参考：Service Authorization Reference：
https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html

②情報漏洩リスクを記載

最初にActionsの各Access Levelについて説明します。

Access LevelのWrite、Permissions management、Read（GetではじまるActionのみ）のActionについて次の観点で情報漏洩リスク評価を行います。Access LevelのListとTaggingは読み取り権限なので評価対象外で問題ありません。

• 情報漏洩リスクとはユーザデータ＝情報資産が外部に漏れるリスクがあるか各Actionの権限を確認します。
• セキュリティのガードレールという考え方に従い、論理的な境界線を意識してその境界線を越えて情報漏洩リスクがあるAction、またはそのガードレール自体を操作(破壊)するリスクのあるActionはリスクを記載します。
• 情報漏洩リスクとなる操作はWriteとPermissions managementが対象となります。また、Readの中でもS3:GetobjectのようにGetではじまる一部のActionはデータ参照権限が含まれるため評価対象とします。

ガードレールとは論理的な境界線を設定し、ユーザの操作を制限する制御機能です。以下の例ではEC2のイメージ（AMI）を外部のアカウントに共有する操作権限をユーザに付与した場合、ガードレールを超えて情報漏洩してしまうリスクがあります。また、ガードレールはIAM権限や暗号化などで設定や対策を行いますが、それら設定を変更してしまう権限もリスクがある操作としてチェックします。以下例のように、基本的にAWSアカウントをガードレールと定義して考えると良いでしょう。

③対策を記載する

情報漏洩リスクのあるAction（操作）は、基本的に次の対策を行います。1つのリスクに対し1つの対策ではなく複数設定する場合もあります。

• 権限分掌：リスクある権限は利用者に付与せず、管理者のみに付与します。もしくは必要なければ管理者、利用者ともに権限は付与しません。
• 一時的な権限付与：リスクがあるがどうしても利用者で使用したい権限は、Sandbox環境では一時的な権限付与も有効な対策と考えます。特定の時間帯であれば利用者の限定やログ解析も容易になります。
• KMS暗号化：ユーザデータは必ず暗号化します。多層防御が設定でき万一情報漏洩した場合も複合できなければ情報漏洩になりません。
• 不正操作の検知：発見的統制の観点で特定のActionが行われた場合に通知します。冒頭説明した前回のブログで紹介した、ControlTowerを利用することをお勧めします。

権限分掌でリスクある権限を付与しないことが最も強い対策ですが、Sandbox環境では利便性が悪くなってしまいます。そのため、一時的な権限付与も有効な手段かと思います。またControlTowerなど利用し、情報セキュリティリスクのある操作の早期発見によりリスクを最小限にすることも有効な対策です。

補足ですがIAMのCondition句などを利用すればポリシーを実行するタイミングで条件を指定することができます。例えば、EC2を起動する操作で特定の「Sandbox」タグが付与されたAMIに限定したい場合は次のようにIAMポリシーを記載します。状況によってはIAMポリシーの設計で細かなアクセスコントロールをすることで利用者に安全に権限を与えることも検討できます。

４．まとめ

• Sandbox環境で新しいAWSサービスを素早く安全に利用するために次の3つの方法が考えられる。
  -Sandbox環境向けIAM権限評価チェックリストを作成して誰でも素早く対応する
  -Sanbox環境の利用部門で責任もってIAM評価と管理を行う
  -AWS Innovation Sandboxソリューションを活用したSandbox分離環境の提供
• IAM権限評価チェックリストでは、まずAWSサービスの特性を把握し、アクセスコントロール(ACL)と暗号化を軸にネットワークと暗号化の6つの項目の確認を行いベースとなる対策が可能か確認する。
• 次にIAM Action評価をAccess LevelのWrite、Permissions management、Read（Get^*）を対象にガードレールを超えて情報漏洩リスクにある操作、ガードレールやセキュリティ対策機能自体を変更するような権限がないかチェックする。
• 最後にリスクある権限について対策を決める。基本的には権限分掌、一時的な権限付与、KMS暗号化、不正操作の検知によるリスクの最小限化をリスク内容に応じ複合的に設定する。

５．最後に

冒頭でも触れましたが、Sandbox環境の目的である開発の自由度を高めつつ、企業の情報セキュリティポリシーに従いながら、利便性の高いSandbox環境を設計することは、一定の難易度があると感じています。本ブログではIAM権限評価や設計について最後は人手で設計や確認する必要がありますが、それをいかに早く誰でも一定のレベルで行えるよう解説させて頂きました。

ビジネス環境の変化やテクノロジーの進化は益々加速してきている状況で、自由度とセキュリティのバランスをいかに素早く対応していくか今後も追及していきたいと考えております。本ブログが皆様の何かの一助になれば幸いです。

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