[レポート]SEC205: 自信を持ってクラウド環境の監査を受けるための専門家のアドバイス #reinvent

こんにちは、臼田です。

本記事はAWSの一大イベントであるre:Inventの下記セッションについてのレポートです。

SEC205 - Confidently Execute Your Cloud Audit: Expert Advice

For security-conscious businesses, SOC 2 compliance is a minimum requirement when considering a cloud-based SaaS or PaaS solution. In this session, AWS and Deloitte deliver a joint workshop designed to help customers who are considering or undergoing SOC 2 compliance be successful, from initiation to delivery. The workshop is interactive, with practical activities derived from real-life challenges that occur throughout the audit life cycle, including planning, scoping, control development, and audit execution. Customers walk away with confidence to execute their own SOC audit to validate the security and compliance of their own cloud applications.

Kristen Haught - Technical Program Manager, AWS Misty Haddox - Customer Audit Manager, AWS Security, AWS Devendra Awasthi - Senior Manager, Cloud Risk & Compliance, Deloitte

SOC 2の必要性や活用方法についてのセッションでした。

レポート

概要

セキュリティに配慮したビジネスを行う際に、特にクラウドのSaaS・PaaSソリューションを提供する場合には、SOC 2への準拠は最低限必要です。

このセッションでは、AWSとDeloitteが、SOC 2コンプライアンスを検討している、または受けている顧客が開始から出荷に至るまで成功するのを支援するためのワークショップです。

SOC 2とは米国公認会計士協会（AICPA）が定めたトラストサービス規準で、その報告書には下記のような役割があります。

SOC2報告書は、アウトソーシング事業者(受託会社)が委託されている業務で、セキュリティ、可用性、処理のインテグリティー、機密保持、およびプライバシーに関連する内部統制を対象として保証を受けた報告書です。

SOC2報告書｜サービス：オペレーショナルリスク｜デロイト トーマツ グループ｜Deloitte

AWSではセキュリティに関する考え方として責任共有モデルを提供していますが、アウトソーシング事業者はこれに当てはめつつユーザのデータを守る必要があります。

その際に、何をどこまで実施すればいいかの一つの判断基準としてSOC 2が利用できます。

ユースケース1: MSP(マネージドサービスプロバイダー)の場合

• 例えばユーザ管理を各社でどのように扱えばいいか
• まずはAWS、MSP、カスタマーそれぞれでどう役割分担するかを検討する
• AWSは責任共有モデルに基づきAWSインフラについてのユーザ管理を行う
• MSPは提供する役割を考慮してインフラ全体におけるユーザ管理を行う
• カスタマーはアプリケーションとデータベースにおけるユーザ管理を行う
• そしてSOC 2に当てはめる
• SOC 2ではユーザ管理はCC 5.2という項目がある

CC 5.2(意訳)

新しい内部および外部のシステムユーザーは、システムクレデンシャルが発行される前に登録および許可され、システムにアクセスする権限が与えられます。 ユーザシステムの認証情報は、ユーザアクセスが許可されなくなったときに削除されます。

• MSPはインフラ全体についてCC 5.2全体及び小項目を満たせるようにサービスを作れば適切なセキュリティを保つことができる。

ユースケース2: 医療スケジューリングシステムのSaaS

• 例えば転送するデータの保護を検討する場合
• アクターはAWS、Messaging Provider、Scheduling SaaS、メディカルオフィスとし、役割分担を考える
• AWSではAWSインフラでの通信中と保存中のデータの暗号化を可能にする
• Messaging ProviderではネットワークのTLSによる暗号化をサポートする
• Scheduling SaaSでは標準の暗号メカニズムを利用してデータを保護する
• メディカルオフィスは患者の健康情報を守る
• そしてSOC 2に当てはめる
• SOC 2では転送するデータの保護はCC 5.7という項目がある

CC 5.7(意訳)

情報の送信、移動、および削除は、許可されたユーザーとプロセスに限定され、送信、移動、または削除中に保護され、セキュリティ、可用性、および機密性に関連するコミットメントと要件を満たすことができます。

• Scheduling SaaSはデータを保護するための暗号化設定を実施してCC 5.7及びその小項目と照らし合わせて問題ないか確認すればいい

コンセプト

• 制御する責任を各アクターで共有する必要があります
• まずはリスクアセスメントを行います
• 管理の所有権を把握し、検証する必要があります
• SOC 2の要件に当てはめます
• 現状にギャップがないか確認し、必要に応じ修正します

まとめ

 

SOC 2の基準を活用してクラウドサービスを提供する事業者がどこまで何をやればいいのか、判断する方法がわかりました。

セキュリティや可用性の確保などは、判断基準が難しいことが多いのでその基準としてはSOC 2は最適だと思います。

サービス提供事業者の場合には、是非活用を検討してみてはいかがでしょうか