Amazon Web Services ブログ

AWS 上に構築した SaaS ソリューションにおけるコンプライアンスの重要性と影響

この記事は、AWS の Sr. Security Partner Strategist である Cheryl Cage および AWS SaaS Factory チーム Sr. Partner Solutions Architect の Bill Tarr が執筆した Importance and Impact of Compliance for SaaS Solutions on AWS を翻訳したものです。

Software-as-a-Service (SaaS) プロバイダーであれば、顧客が信頼のおける SaaS ソリューションを採用しようとしていることをよくご存知でしょう。貴社のソリューションが信頼でき、ニーズに合わせて拡張可能である中で、最も重要なことは、顧客の貴重なデータ資産を保護できるという信頼です。

セキュリティとプライバシーの標準に準拠することは、そのソリューションが業界標準を満たし、顧客の期待に沿ってユーザーデータを取り扱っていることを顧客に伝える効果的な方法です。

セキュリティポスチャを改善し、SaaS ビジネスを成長させる上で、コンプライアンスは戦略の重要な一部となり得ます。

  • 法的要件: SaaS 企業は、データ保護、プライバシー、セキュリティに関連する様々な規制や法律の適用を受けることが多くあります。これらの規制を遵守することは、法的に義務付けられているだけでなく、高額な罰金や法的措置の回避にもつながります。
  • 信頼と評判: 顧客は SaaS 企業に機密データを託し、それが保護されることを期待しています。業界標準や規制に準拠することは、信頼の構築と維持に役立ちます。
  • 新規市場への参入: 特に規制の厳しい業界では、新規市場への参入や特定の顧客との取引に際して、特定の基準や規制の遵守が求められる場合があります。
  • リスク管理: コンプライアンスは、SaaS 企業がデータ保護とセキュリティに関連するリスクを特定し、管理するのに役立ちます。その要件には、リスクを軽減し、データ侵害を防止するためのポリシー、手順、およびコントロールの実装が含まれることがよくあります。

コンプライアンスに対応した計画を構築することは、SaaS ソリューションの設計やアーキテクチャにも影響を与え、将来的な技術的負債を回避するのにも役立ちます。

この記事では、SaaS プロバイダーがコンプライアンスに準拠したソリューションを設計・構築する際に考慮する必要があるいくつかの要素を分類し、それらに関連する Amazon Web Services (AWS) 内のリソースやサービスをご紹介します。

セキュリティ基盤としてのコンプライアンス

セキュリティとプライバシーのフレームワークは、サイバーセキュリティプログラムを構築し、ポリシーと手順を確立するためのツールを提供し、情報の機密性、可用性、完全性を保護するために必要な技術的な管理を実装します。これらのフレームワークは、リスクを管理し、脆弱性を低減するための青写真を提供し、組織が直面するリスクと攻撃者がセキュリティの弱点をどのように悪用するかを考慮するように設計されています。

SaaS プロバイダーにとって、これらのフレームワークは自社のソリューションが、政府の法律や特定業界の規制に関わらず、顧客のセキュリティ要件を満たしていることを証明するために使用することができます。

場合によっては、企業は業務改善や競争力強化のために、Service Organization Control 2 (SOC2: サービス組織の統制) や International Organization for Standardization 27001 (ISO27001: 情報セキュリティマネジメント) などの認定や認証を取得することがあります。また、支払いカード情報や個人情報 (PII) や、その他のセンシティブなデータをどのように取り扱うかについて、規制遵守義務を果たし法律を遵守しなければならない場合もあります。

フレームワークのセキュリティ要件は、一般的にセキュリティのある側面を定義する一群の統制に対応します。これらの管理策は、準拠の自己宣誓を要求する場合もあれば、第三者による宣誓を要求する場合もあります。第三者による宣誓の場合は、定期的なレビュー形式をとる場合もあれば、管理策の準拠状況を監視するシステムによる継続的な準拠を要求する場合もあります。

コンプライアンスの達成は継続的なプロセスとなりますが、定期的なモニタリングとレポーティングを行うことで、これらのフレームワークの遵守をビジネス運営の標準的な部分とすることができます。適切なセキュリティ管理、データプライバシー、データ管理は、SaaS アプリケーションの最初から基本的な構成要素であるべきです。

責任共有モデルとコンプライアンス

AWS 上に SaaS を構築されるプロバイダーにとって、コンプライアンスの観点から責任共有モデルを理解することは重要です。AWS は継続的に監査を受けており、SOC 2、ISO 27001、Federal Risk and Authorization Management Program (FedRAMP: 米国政府機関におけるクラウドセキュリティ認証制度)、Payment Card Industry Data Security Standard (PCI DSS: クレジットカード業界の情報セキュリティ基準) など、世界中の認証や認定を維持し、顧客がセキュリティやコンプライアンス要件を満たせるよう支援しています。

AWS クラウド上でシステムを構築する場合、AWS とお客様 (SaaS プロバイダー) はこれらのコンプライアンス責任を共有します。以下の図 1 で示すように、コントロールによっては AWS から継承されたり、共有されたり、あるいは顧客の責任となるものもあります。

AWS が SOC 2 認証、FedRAMP 認証、ISO 認証を持っているように、コンプライアンスが必要な SaaS プロバイダーも同じコンプライアンスプロセスを経なければなりません。SaaS プロバイダーは、自社の環境を構成するサービスの範囲内で、どのコンポーネントに責任があるのかを理解することが重要なのです。

AWS 責任共有モデル

図 1 – AWS の責任共有モデル

SaaS アーキテクチャを計画する上で重要なリソースをいくつか挙げてみます。

  • Customer Compliance Guides (CCG) は、AWS サービスの設定可能なオプションと、一般的なフレームワーク (SOC 2、ISO 27001、FedRAMP、National Institute of Standards and Technology Cybersecurity Framework (NIST CSF)) にマッピングされたコンプライアンスのトピックとコントロール要件に基づいて、AWS のセキュリティプラクティスの統合ビューを提供します。
  • コンプライアンスプログラムによる対象範囲内の AWS のサービスは、特定のコンプライアンスフレームワークや規制に対して評価され、承認されたサービスのリストです。例えば、Health Insurance Portability and Accountability Act (HIPAA: 米国の医療保険の携行性と説明責任に関する法律) については、お客様は HIPAA アカウントとして指定されたアカウントで AWS サービスを使用することができますが、このページおよび Business Associate Addendum (BAA: 業務提携補遺) で定義された HIPAA 適格サービスにおいてのみ、保護されるべき医療情報 (PHI) を処理、保存、送信することができます。
  • AWS Artifact は、AWS のコンプライアンスレポートへのアクセスを提供し、AWS と SaaS プロバイダーであるお客様との間で、コンプライアンスに関する監査から要求される可能性のあるアグリーメントを提供します。一部のレポートでは、「クラウドの」継承可能なコントロールがリストアップされ、共有されるコントロールの範囲とその責任をお客様が理解するのに役立ちます。

SaaS アーキテクチャにおけるコンプライアンスの影響

以降のセクションでは、コンプライアンスに関する懸念が、SaaS における数々のコアコンセプトに関する考え方に、どのような影響を与えるかを検証していきます。その際、SaaS アーキテクチャの基礎に関する AWS ホワイトペーパーと、AWS Well-Architected Framework の SaaS レンズを参照していきます。一般的な SaaS ガイダンスとして、これらのガイドを参照してください。

テナント分離の意味

テナントの分離とは、テナントのリソースを保護し、他のテナントのリソースへのアクセスを拒否するプロセスです。SaaS においてテナントインフラを分離する選択肢は、主に「サイロ」と「プール」に分けられます。SaaS ホワイトペーパーの「フルスタックのサイロとプール」セクションにてその背景をご確認ください。

図 2 – サイロ型とプール型のテナント分離モデル

コンプライアンスフレームワークや規制、特に規制の厳しい業界を対象とするコンプライアンスフレームワークや規制が、プールされたリソースの使用を禁止しているというのは誤解です。実際、ほとんどのフレームワークではテナントの分離に関するガイダンスは提供されておらず、FedRAMP でさえ、主に「あるテナントの暫定的なアクセスを使用して別のテナントを侵害しようとする完全なアプリケーションテスト」(FedRAMP Penetration Test Guidance) を指定しています。

「アーキテクチャの全レイヤーにわたって分離戦略を導入し、テナントリソースへのアクセスの試みが現在のテナントコンテキストに対して有効であることを保証する、特定の構造を提供する」(SaaS Lens) ことを証明できるように準備してください。

リソースをプールするのであれば、アプリケーションの各レイヤーで分離ポリシーが適用されていることが重要です。図 3 では、API、コンピュート、ストレージの各レイヤーでどのように分離ポリシーを適用する必要があるかがわかります。AWS Identity and Access Management (IAM) はプールされたリソースの分離に不可欠であり、Dynamic Policy Generation (動的なポリシーの生成) や Attribute Based Access Control (ABAC: 属性ベースのアクセス制御) のような技術は、分離ポリシーを適用するメカニズムを提供します。

図 3 – SaaS ソリューションにおける分離ポリシー

ほとんどのコンプライアンスフレームワークでは、プールされたリソースを明示的に禁止していないにもかかわらず、規制の厳しい業界にサービスを提供する SaaS プロバイダーは、顧客の要望に対応する必要がある場合があります。このようなサイロ型リソースのリクエストに対応するために、より高コストの価格設定階層としてサイロ型リソースが必要になる場合があります。

コンプライアンスを遵守したテナントオンボーディング

サイロ環境では、すべてのテナント環境で同じ準拠バージョンのソフトウェアを実行していることを確認する必要があります。新しいテナントが加わり、ソフトウェアの新バージョンを展開する際には、すべてのテナントが実行しているバージョンがコンプライアンス基準を満たしていることを保証する必要があります。

図 4 – コンプライアンスを遵守したテナントのオンボーディング

AWS Organizations と AWS Control Tower は、テナントの一元的なプロビジョニングと、アカウントの偶発的な変更を防止するサービスコントロールポリシー (SCP) のガードレールの設定を支援します。また、Landing Zones Accelerator on AWS (LZA) は、ログアーカイブと監査アカウントによるセキュリティ構成の設定を支援し、アクティビティの証跡を監査が利用できるようにします。

データストレージにおけるコンプライアンスの影響

SaaS ソリューションにおけるデータに関する議論は、テナントデータのパーティショニング方法を理解することから始まります。ある意味、これはテナントの分離と似ていますが、次のことを考慮してください。「データパーティショニングとテナント分離は、しばしば互換性があるとみなされがちです。この 2 つの概念は等価なものではありません。データパーティショニングというのは、個々のテナントのデータをどのように保存するかということです。」(SaaS ホワイトペーパー)

テナントの分離と同様に、コンプライアンス目的でデータをどのように分割するかを検討する必要があります。これには分離の問題だけでなく、データの機密性に基づいて分離を決定することも含まれます。

図 5 – センシティブな SaaS データの分離

データパーティショニングの決定は、データの暗号化要件、バックアップとリストアのポリシー、データ保持、データ主権、オフボーディングに関与する可能性があります。

例えば、Amazon Simple Storage Service (Amazon S3) のバケットとそのフォルダは、デフォルトで AWS Key Management Service (AWS KMS) で暗号化するように設定することができ、テナント固有のキーで暗号化されたデータのオプションを提供します。

図 6 – テナント Amazon S3 データの暗号化

マルチテナントの監査、ログ、モニタリング

ログ、トレース、メトリクスを含め、アプリケーションが出力するすべてのものにテナントの概念をインジェクトする必要があります。コンプライアンス目的のためには、ログが一元化されたログソリューションに集約され、監査アカウントでログへのアクセスが制限されていることを確認することが重要です。

リソースへのアクセス履歴を確認するためはに、すべてのアカウントとリージョンに対して AWS CloudTrail をオンにします。例えば、Amazon API Gateway への呼び出しのログ記録や Amazon Cognito API 呼び出しのログなどです。

テナントアイデンティティの管理

テナントユーザーとその SaaS ソリューションへのアクセスも管理する必要があります。これには、ユーザーが認証され、特定のテナントコンテキストに接続されていることを確認することも含まれます。このコンテキストには、先ほど説明したロギングやモニタリングなど、アプリケーションの各レイヤーに渡す情報が含まれます。

テナントのサービスやロジックがソリューション全体に分散するのではなく、テナントのアイデンティティを一元管理することで、コンプライアンスに関するストーリーが強化されます。ID プロバイダ (IdP) を活用することで、アイデンティティ管理に継承可能なコントロールを提供し、コンプライアンス遵守への道筋を簡素化することができます。

セキュリティとコンプライアンスを始める

SaaS のコンプライアンスが困難である理由をいくつか見てきました。多くの SaaS プロバイダーにとって、これは顧客がどのようなコンプライアンスフレームワークを要求するかがまだ分からなくても、少しずつ前進することを意味するかもしれません。

コンプライアンスフレームワークによって定義された多くのコントロールと要件は、クラウドアーキテクチャのベストプラクティスに基づいています。AWS は、お客様のソリューションがベストプラクティスに従っていることを確認できる無償のリソースをいくつか提供しており、それらは将来のコンプライアンス要件を見越してアーキテクチャを準備するのに役立ちます。

AWS パートナーネットワーク (APN) のメンバーは、AWS Global Security and Compliance Accelerator (GSCA) を含む、SaaS プロバイダーが顧客のコンプライアンスニーズを満たすためのプログラムを活用することができます。AWS SaaS Factory プログラムは、SaaS のあらゆる段階で SaaS プロバイダーに専門的なガイダンスを提供します。

まとめ

この記事では、AWS におけるコンプライアンスの様々な側面を検証し、SaaS のベストプラクティスとコンプライアンス要件を照らし合わせながら、SaaS アプリケーションを設計、構築する際に留意すべき事項について検証してきました。

SaaS ソリューションを構築する際に、コンプライアンスのベストプラクティスに合わせるために活用できる数多くの無償リソースをご紹介し、最後に、AWS コンプライアンスサービスを使用してソリューションを監視する方法について説明しました。

AWS SaaS Factory について

AWS SaaS Factory は、SaaS 導入のどの段階の企業でも支援します。新製品の構築、既存のアプリケーションの移行、AWS 上での SaaS ソリューションの最適化など、どのようなご要望にもお応えします。AWS SaaS Factory Insights Hub では、技術的、ビジネス的なコンテンツやベストプラクティスをご覧いただけます。

また、SaaS 開発者の方は、エンゲージメントモデルや AWS SaaS Factory チームとの連携について、アカウント担当者にお問い合わせください。

こちらにご登録いただくと、最新の SaaS on AWS ニュース、リソース、イベントの情報を入手できます。

AWS Global Security and Compliance Acceleration について

Global Security and Compliance Acceleration on AWS Program (GSCA) は、金融サービス、ヘルスケア、プライバシー、公共部門のセキュリティ、プライバシー、コンプライアンス要件を満たす必要のあるビジネスを、グローバルにサポートします。これには商業部門と公共部門の両方のワークロードが含まれます。

AWS パートナーは、コンプライアンスプログラムの要件を理解し、GSCA チームと連携するために、担当者に連絡を取ることをお勧めします。

翻訳はソリューションアーキテクト 杉本 晋吾 が担当しました。原文はこちらです。