SOC2 Type2取得のためのAWS設計・運用

はじめに

こんにちは、株式会社スマートラウンドVP of Reliabilityの@shonansurvivorsです。SREやコーポレートIT等を担当しています。

弊社プロダクトであるsmartroundは、セキュリティ等に関する第三者評価であるSOC2 Type2監査を受け、その保証報告書を受領しました(以降、「SOC2 Type2取得」と表現します)。

https://prtimes.jp/main/html/rd/p/000000072.000042542.html

smartroundはAWS上で稼働しており、AWSの各種設計・運用についても、SOC2 Type2の求める水準に対応していく必要がありました。本記事では、そのためにどのような取り組みを行なっているかを解説します。

SOC2 Type2とは

SOC2とは、クラウドサービス等のセキュリティに関する内部統制を、外部の監査法人が評価する枠組みです。米国公認会計士協会（AICPA）が定めたトラストサービス規準に基づいて評価が行われます。

SOC2のトラストサービス規準は、

• セキュリティ
• 可用性
• 処理の完全性
• 機密保持
• プライバシー

の5つから構成されます。うち、セキュリティの監査の実施は必須であり、残る4つの監査を実施するかどうかは、監査を受ける組織が選択します。

smartroundでは上記5つの規準全ての監査を受け、それらの内部統制の有効性が確認されています。

また、SOC2にはType1とType2の2種類があります。両者の違いは以下になります。

• Type1：特定の日付における内部統制の設計の適切性が監査されます
• Type2：一定の期間における内部統制の運用の有効性が監査されます

監査結果は報告書としてまとめられ、サービスを利用中あるいは利用検討中の企業はこの報告書を見ることで対象サービスの内部統制の状況を確認することができます。

評価対象期間の長いType2報告書の方が、より客観的な信頼性が高いといえます。

smartroundでは、昨年2024年9月にType1報告書を受領し、その後2025年2月にType2報告書を受領しました。

本記事を読んでいただく上での注意点

この後、smartroundにおけるAWSの整備・運用の内容に触れていきますが、それらを行うだけでSOC2を取得できるわけではないことに留意してください。

SOC2のスコープのうち、AWSに直接的に関わらないか、あるいはAWSだけで完結しない要素は複数あり、例えば以下のようなものがあります。

• 経営層のセキュリティへの関与
• 各種ポリシー(規程)の整備と従業員への周知
• 従業員の採用基準や評価制度の整備
• 従業員へのセキュリティ教育
• 従業員が使うPC等デバイスのセキュリティ
• AWS以外も含むサードパーティ管理
• アプリケーションコードを含む開発のルール
• ペネトレーションテストの実施

など。

つまり、SOC2においては、AWSのようなインフラは非常に重要ではあるものの、全体のスコープの中では一部分であるということです。

また、SOC2は米国公認会計士協会の定める規準に基づいて実施されるものの、監査を行う監査法人によって、個々の判断は微妙に異なることが予想されます。実際のSOC2監査においては、担当の監査人とよく対話しながら対応を進めていくようにしてください。

SOC2 Type2取得のためのAWS設計・運用

ここからは、SOC2 Type2取得のためにsmartroundで実践しているAWS設計・運用に具体的に触れていきます。

Security Hubの基準に準拠する

SOC2で、インフラにも関わるような要件を一部抜粋すると、以下のようなようなものがあります。

• CC6.1 組織は、情報資産をセキュリティイベントから保護するために、論理アクセスセキュリティソフトウェア、インフラストラクチャ、およびアーキテクチャを実装します
• CC6.6 組織は、システム境界外からの脅威から保護するために、論理アクセスセキュリティ対策を実装します

CCから始まるIDは、SOC2の共通規準(Common Criteria)の番号を示しています。SOC2ではセキュリティに関してはCC1からCC9までの規準があり、CC6は「論理的および物理的アクセス」に関する規準となります。

このような情報資産の保護に関する要件に対応していくことをS3を例に考えると、ブロックパブリックアクセスの有効化は効果的な手段のひとつといえるかと思います。

このS3のブロックパブリックアクセス有効化は、Security Hubに用意されている基準(Standard)内のコントロールでもフォローされており、もし有効化されていないS3バケットがあれば自動で検出してくれます。

S3以外の各AWSリソースに対しても、Security Hubには情報資産の保護に関するコントロールが同様に多数存在します。

つまり、Security Hubの基準内にある各コントロールをひとつひとつ合格させていくと、自然とSOC2でインフラに求められる要件に準拠できていく(準拠できていると説明できる)ことになります。

利用するSecurity Hubの基準としては、以下のようなものが網羅的で良いかと思います。

• AWS 基礎セキュリティのベストプラクティス v1.0.0

あるいは

• NIST Special Publication 800-53 Revision 5

GuardDutyで検出した脅威に対応する

前述のSecurity Hubでは、脅威検出サービスであるGuardDutyの有効化が求められています。有効化すればSecurity Hubとしては合格となるのですが、SOC2としては脅威が検出された後に適切なアクションを行なっていることも求められます。

• CC7.2 組織は、悪意のある行為、自然災害、および組織の目標達成能力に影響を与えるエラーを示す異常について、システムコンポーネントおよびそれらのコンポーネントの動作を監視します。異常は、セキュリティイベントを表すかどうかを判断するために分析されます。

例えば検出結果をSlack通知する設定を行なっておくことは、適切なアクションを開始するための最低限の仕組みを整えていることを示すことになるでしょう。

以下は、リージョン集約済みのSecurity Hub管理アカウントを通じて、各AWSアカウントのGuardDutyの検出結果を一元的にSlackへ通知する構成例です。

EventBridgeのイベントパターンの設定例は以下です。

{
  "detail": {
    "findings": {
      "ProductName": ["GuardDuty"],
      "RecordState": ["ACTIVE"],
      "Workflow": {
        "Status": ["NEW"]
      }
    }
  },
  "detail-type": ["Security Hub Findings - Imported"],
  "source": ["aws.securityhub"]
}

上記の仕組みがサポートするのはあくまで通知を行うところまでなので、その後の対応方針についても定義し、これを運用するようにしてください。

Inspectorで検出された脆弱性を管理する

Inspectorを有効化した上で、組織のポリシーに基づいて、検出された脆弱性に対処します。

• CC7.1 目標を達成するために、組織は、（1）新しい脆弱性の導入につながる構成の変更、および（2）新たに発見された脆弱性に対する脆弱性を特定するために、検出および監視手順を使用します。
• CC5.3 組織は、期待される内容を定めるポリシーと、ポリシーを実行に移す手順を通じて、統制活動を展開します。

ポリシーはドキュメントに定義し、経営層の承認を受けておくようにします。

ドキュメントは「脆弱性管理ポリシー」として新規に作成しても良いですし、既に「システムリスク管理規程」や「情報セキュリティ管理規程」と呼ばれるようなドキュメントが存在するのであれば、そこに脆弱性管理の条文を追加しても良いと思います。

Inspectorでは検出した脆弱性にそれぞれ重大度が設定されますが、ポリシーでもこうした重大度に応じた対応基準を定めます。

例えば「緊急」のものは1日以内、「高」のものは7日以内、「中」のものは30日以内に解消させる、といった具合です。

上記の期間はあくまで例であり、この水準でないとSOC2を取得できないというわけではありません。重要なのは組織によって承認されたポリシーに基づいて脆弱性の管理を行うということです。

IAMの付与にあたっては承認プロセスを経る

エンジニアの入社や異動に伴って、そのエンジニアのためのIAMユーザーあるいはIAM Identityユーザーを発行するケースがあるかと思います。

こうした場合、承認プロセスを経た上で権限の付与を行うようにします。

• CC6.1 組織は、保護された情報資産をセキュリティイベントから保護するために、論理アクセスセキュリティソフトウェア、インフラストラクチャ、およびアーキテクチャを実装する。
• CC6.2 組織は、システム資格情報の発行およびシステムアクセス権の付与に先立ち、組織によって管理されるアクセス権を持つ新規の内部および外部ユーザーを登録および承認する。ユーザーのアクセスが承認されなくなった場合、ユーザーのシステム資格情報は削除される。
• CC6.3 組織は、組織の目的を達成するために、役割、責任、またはシステム設計および変更に基づいて、データ、ソフトウェア、機能、およびその他の保護された情報資産へのアクセスを承認、変更、または削除し、最小特権と職務分掌の概念を考慮する。

承認プロセスが証跡として残るよう、チケット管理システム等でチケットとして発行しておきます。

承認にあたっては、付与する権限がその人の役割に対して適切であるかどうかをレビューするようにします。

なお、ここではAWSリソースの中でもIAMを採り上げて「承認プロセスが必要」と説明しましたが、他のAWSリソースの変更に関して承認プロセスが不要というわけではありません。IAMに関しては、アクセス権の付与という文脈で承認プロセスを必要としており、他のAWSリソースに関しては変更管理の文脈で承認プロセスを必要とします。これについては後ほど触れます。

IAMが不要になったら速やかに削除する

退職などの理由でその人にIAMが不要になった場合は速やかにこれを削除します。

この場合も権限付与の時と同様、証跡が残るようにチケット等を発行するようにします。

IAMの定期的なレビューを行う

発行済みのIAMユーザー等の権限が適切か、退職等で不要となったIAMが放置されていないか等をチェックするために定期的なレビューを行います。

• CC6.2 組織は、システム資格情報の発行およびシステムアクセス権の付与に先立ち、組織によって管理されるアクセス権を持つ新規の内部および外部ユーザーを登録および承認する。ユーザーのアクセスが承認されなくなった場合、ユーザーのシステム資格情報は削除される。

例えば、以下を定期的に行うことが考えられます。

• IAM Access Analyzerの認証情報レポートを確認する
• IAM Identity Centerのユーザー、グループ、許可セットを確認する
• Security HubでIAMに関するコントロールが失敗していないか確認する

など。

AWSリソースの変更にあたっては定められたプロセスを経る

AWSリソースの変更にあたっては組織で定められたプロセスを経るようにします。

• CC8.1 組織は、インフラストラクチャ、データ、ソフトウェア、および手順に対する変更を承認(authorize)、設計、開発または取得、構成、文書化、テスト、承認(approve)、および実装し、その目的を達成する。

これに関しては、組織によって様々な開発プロセスがあると思いますので、それをベースにしつつ、上記の規準に対して不足があるようであれば補うことを検討してください。

AWSをサードパーティのひとつとしてリスク管理する

ここでのサードパーティとは、自組織がサービスを提供するために業務上の関係や契約等を有する他の組織を指します。外部委託先やクラウドサービスプロバイダなどを想定しています。

SOC2では、こうしたサードパーティのリスクを評価し、管理することが求められます。

• CC9.2 組織は、ベンダーおよびビジネスパートナーに関連するリスクを評価し、管理します。

smartroundにとってはAWSもサードパーティの1つであるため、組織で定めたサードパーティリスク管理のポリシーに沿って管理を行います。

具体的には、そのサードパーティで取り扱っているデータの重要度や、障害が発生した時のインパクトなどを元にリスクレベルを判定し、そのリスクレベルに応じた管理を行います。

smartroundではAWSをリスクレベルとして最も高い「高」として取り扱っており、このような「高」のサードパーティにはSOC2 Type2か、これに相当する第三者評価を取得していることを求めるポリシーとしています。

AWSはSOC2 Type2を取得しており、マネジメントコンソールのAWS Artifactの画面でSOC2 Type2報告書をダウンロードできます。smartroundでは、年に一度この報告書を確認する運用としています。

可用性を監視する

SOC2の可用性に関する規準のひとつとして、キャパシティ管理があります。

• A1.1 組織は、その目標を達成するために、キャパシティ需要を管理し、追加キャパシティの実装を可能にするために、システムコンポーネント（インフラストラクチャ、データ、およびソフトウェア）の現在の処理能力と使用状況を維持、監視、および評価します。

Aから始まるIDは、SOC2の中でも可用性に関する規準です。

このキャパシティ管理に関する規準を見ると、システムコンポーネントとその処理能力に着目しており、Site Reliability Engineeringの文脈で語られるような、ユーザーの体験に着目した監視の観点は含まれてはいません。

SLI/SLOを導入済みで、個々のシステムコンポーネントの処理能力(CPU使用率など)を積極的に監視していない組織においては、可用性や信頼性の監視に対する解釈で、監査人とギャップが生じるかもしれません。

もし、CPU使用率などの監視が必要ということになれば、対応するCloudWatchメトリクスを、CloudWatch Alarmを使って監視することを検討してください。

ちなみにSOC2の規準も数年に一度アップデートされるようなので、今後SLI/SLOやその周辺の概念もSOC2に導入されたら良いな、と思っています。

バックアップのリストアテストを行う

SOC2の可用性に関する規準では、バックアップとリストアに言及した箇所もあります。

• A1.2 組織は、その目標を達成するために、環境保護、ソフトウェア、データバックアッププロセス、およびリカバリインフラストラクチャを承認、設計、開発または取得、実装、運用、承認、保守、および監視します。

RDS標準の自動バックアップ機能あるいはAWS Backupを使って重要なデータのバックアップを常時行なうようにします。また、バックアップデータをリストアするテストを四半期ごとなど定期的に実施するようにします。リストアテストでは目標復旧時間(RTO)および目標復旧時点(RPO)を満たしていることを検証します。

インシデント対応計画・災害対策計画・事業継続計画を策定し訓練する

SOC2ではインシデント対応計画や災害対策計画、事業継続計画の策定と訓練を求められます。

• CC7.3 組織は、セキュリティイベントを評価して、組織の目的の達成失敗（セキュリティインシデント）を引き起こす可能性があるか、または引き起こしたかを判断し、もしそうであれば、そのような失敗を防止または対処するための措置を講じる。
• CC7.4 組織は、特定されたセキュリティインシデントに対応するために、定義されたインシデント対応プログラムを実行して、セキュリティインシデントを理解、封じ込め、修復、および適切に伝達する。
• CC7.5 組織は、特定されたセキュリティインシデントからの復旧活動を特定、開発、および実装する。
• CC9.1 組織は、潜在的な事業中断から生じるリスクに対するリスク軽減活動を特定、選択、および開発する
• A1.3 組織は、その目標を達成するために、システムリカバリをサポートするリカバリ計画手順をテストします。

smartroundでは、各計画について以下のような棲み分けとしています。

• インシデント対応計画
  • 不正アクセスや情報漏えいのようなセキュリティインシデントのほかに、システムのバグ等を起因とする、いわゆるシステム障害全般もスコープとし、その検知から復旧プロセスと、その後のポストモーテムを扱う
• 災害対策計画
  • 被災等によるAWSの東京リージョン全面停止を想定し、大阪リージョンへの切替プロセスを扱う
• 事業継続計画
  • 何らかの理由で事業継続が困難になった際の復旧プロセスを扱う

この中では災害対策計画が最もAWSに関連性が高いものとなっており、大阪リージョンへの切替訓練を年1回は実施するようにしています。

おわりに

以上、SOC2 Type2取得のためのAWS設計・運用の解説でした。SOC2取得を検討されている方に本記事がお役に立てば幸いです。

また、スマートラウンドでは全職種で仲間を募集中です。本記事を読んで興味を持たれた方はぜひ以下もご覧ください。

https://jobs.smartround.com/

カジュアル面談も随時受け付けています。お気軽にお申し込みください。

• カジュアル面談応募フォーム