シンジです。そもそもSOC報告書は、プライバシーマークやISMSのような認証規格ではありません。cloudpackの運用フローも大きく変わります。今回は、cloudpackの観点からSOCをご説明します。
SOC報告書とは何か
受託業務に係る内部統制の保証報告書(SOC報告書:Reporting on Controls at a Service Organization)の事を言います。 cloudpackがお客様へサービスを提供する際に、このサービスを提供するcloudpackの内部統制のデザインや運用状況について、監査法人や公認会計士が独立した第三者の立場から客観的に検証した結果を記載したものです。報告書では、一定の基準やガイダンスに基づく合理的な保証(絶対的ではないものの、相当程度に高いレベルでの意見)が表明されます。
あくまでも報告書
報告書にはcloudpackの内部統制のありのままが記載されます。具体的にどのような内部統制が整備されているのか、また、それはちゃんと運用されているのか。もし、ちゃんと運用されていなければ、その旨がはっきりと書かれます。
相当程度に高いレベルとはどれくらいか
- ISMSの認証取得を1倍とします
- プライバシーマークは1.5倍くらいな気がします
- PCIDSSは3倍くらい大変でした、特に継続が辛いです
- SOC2は50倍くらい気を使います
- (個人の感想です)
SOC1, SOC2, SOC3とあるが、役割が違うだけ
作成目的、利用用途、配布先の対象が異なります。
- SOC1とは
- 業務を委託する会社の財務諸表が誤るリスクが対象。財務諸表監査で利用
- 米国基準:AT801(SSAE16)、国際基準:ISAE3402、日本基準86号
- SOC2とは
- セキュリティ、可用性、処理の一貫性、機密保持、プライバシーが阻害されるリスクが対象
(cloudpackの場合は、セキュリティ及び可用性に絞っています) - 米国基準:AT101
- 報告書の利用者は評価の対象となるサービスの顧客
- セキュリティ、可用性、処理の一貫性、機密保持、プライバシーが阻害されるリスクが対象
- SOC3とは
- セキュリティ、可用性、処理の一貫性、機密保持、プライバシーが阻害されるリスクが対象
- 日本基準:IT2号、米国基準:AT101
- 不特定の利用者(公開利用)
- 整備されている内部統制手続きはSOC2に比べて簡便な記述になります
Type1 と Type2 があるが、監査期間が違うだけ
- Type1(時点評価)
- とある1日を切り出して監査する
- 現在cloudpackが評価中のものがこれになります
- Type2(期間評価)
- 一定期間を切り出して、その期間の運用状況を監査する
- 来年cloudpackが評価される予定のものになります
cloudpackのサービスプラン全てがSOC2対応となる
これまで案件ごとに個別に調整されたり、暗黙的に行われてきたcloudpackの作業が全て可視化されました。
エンジニアによる本番環境へのシステム変更については、cloudpack内で利用する「システム変更手順書」に従って変更されます。
SOC2対応では、本番環境においてのみ、全ての作業を社内のダブルチェック、机上での影響テスト確認、更に、作業の是非をお客様にご承認頂く必要があります。
システム変更手順書の一部を引用します。
担当者は、原則として逐次の報告について顧客より承認を得るものとする(逐次承認)。
迅速な対応を要する変更作業において、報告時に顧客より速やかな承認の返答が得られない場合は、電話等により顧客の承認を得るようにし、その旨をコメントにて記録する。
但し、顧客よりあらかじめ事前の承認(事前承認)がなされた場合は、逐次承認を行わなくてもよい。
1)以下の作業実施について、あらかじめ(契約時等にて)顧客より事前承認を得ている場合
- サービス運用に必要な管理パッケージ、ツールのインストール
- 監視閾値設定の追加
- AWSへの問い合わせ対応
- 障害調査におけるサーバリソース調査の為のスクリプト実行
- 障害対応に伴う再起動
- 障害対応・急激なアクセス増加に伴う緊急スケールアウト・スケールアップ(バースト保障)
- バグ起因の障害対応に伴うアップデート
- サイバー攻撃への対処
2)上記1)以外の作業実施について、顧客より事前承認を得ている場合
これからcloudpackをご利用なさる場合
SOC2対応のcloudpackサービスが標準でご利用頂けます。
既にcloudpackをご利用頂いているお客様の場合またはSOC2運用を希望されない場合
原則として、SOC2対応のcloudpackサービスが運用されます。ただし、特別なご要望を頂いた場合や、特殊な環境の場合(踏み台サーバーが使えない、Backlogで証跡を残せないなどは)、これまでどおりの運用方法にてご提供可能です。
これらは、cloudpack Classic(仮称) として社内で取り扱われます。
cloudpack Classic(仮称)では、予めリスクが何かをユーザー様とお互いに共有した上で、ある程度自由にサービスを取り扱おうとするのが狙いです。小規模のサービスであったり、影響度が小さいサービスまでを、SOC2運用としなくても良いのでは、とお考えになるお客様を対象としています。
お客様にご提供中のサービスがSOC2運用対象かどうかのご確認が必要な際には、弊社担当者までご連絡下さい。
SOC2運用における作業の承認制度については、本番環境への移行前のタイミングで作業への 「お客様からの事前承認を得る」 事で、高いセキュリティレベルを保ったSOC2運用に乗せながら、cloudpackサービスをより良いスピード感で運用可能です。これらの詳しい内容について不明点がありましたら、担当者までお問い合わせください。
SOC2報告書は8月受領予定
受領が完了しましたら、改めて発表させて頂きます。