シンジです。予定通り8月末に受け取りました。2年かかりました。そもそもSOC2とは何なのかというのは以前のブログで簡単にご紹介しましたので、SOC2レポートを受領するまでの辛い辛い道のりの思い出でも書こうと思います。
何事にも基準が必要
セキュリティといっても、何がどうあるべきかという基準が必要です。SOC2的に言うと、多くのクライテリア（基準）が用意されていて、各クライテリアから見たときに、cloudpackの姿がどうであるか、ありのままにレポートに記述されるという末恐ろしい監査がSOC2です。
良いところも悪いところも全部書かれる
悪いところを、悪いように書いて欲しい企業はそうそういないとは思いますが、cloudpackもその通りで、「これこのまま書かれたらお客様に見せられるレポートにはならないよね。。。」というわけで、あちらもこちらも刷新していったわけです。
SOC2の話があがった当時、シンジは自社Web更新してました
せこせことHTMLやCSSをごにょごにょしたり、Photoshopで画像加工したりするのがお仕事でした。そもそもcloudpackに入社した当初はプロジェクトマネージャーとして入りましたが、直後に客先常駐となり、Deep Securityやシステムバックアップの仕様書やマニュアルを仕上げるお仕事をしていました。
きっかけはアンチウィルスソフトウェア
会社で買ってたライセンスがちょうど切れるとか何とかで、席が隣りだった当時の情報セキュリティ管理責任者（既に個人的な事情で退社）（しかも新卒）が頭を抱えていたわけです。そこで、あれがいいんじゃねーか、これがいいんじゃねーかと口出ししてたらいつのまにやらSOC2対応メンバーになることに。
セキュリティ対策なんてやったことないですが
まぁでも誰もやらないならやるか。というか、cloudpackには最強のCTO・鈴木宏康がいるので何の心配もありませんでした。私が死んでも代わりはいるもの的~~~~
当時もセキュリティが甘いわけでは無かった
ただ、「性善説」が前提にありました。SOC2では「性悪説」を前提にされます。社内に悪いことをしようとする人間がいて、これが悪いことをしたときに、会社は対応出来るだけの能力があるかどうか、ということです。そこで必要になるのは、教育・ワークフロー・システム・強固なファシリティ、まぁ全部ですね。
まずは情報資産の統制から始めた
cloudpackはISO 27001を取得していますので、この辺は割とスンナリでしたが、かなり人的な部分が多かったので、これを自動化するところから始めました。まずはクライアントマシンに入っているソフトウェアの管理やライセンスの管理などです。ついでに操作ログも収集すれば、悪意ある行為のログを取得出来るというわけです。そしてクラウドストレージへのアクセス権限見直し、棚卸し、レビュー記録です。しかしだんだんそれすらも面倒になっていくのです。
Active Directoryの導入とシングルサインオンの検討
全てのサービスにADのアカウントでシングルサインオンできれば、それぞれのパスワードポリシーを評価しなくてもいいし、パスワード更新頻度も確認しなくて良いし、なんかいろいろ便利になるんじゃないのってことで検討を始めました。そしてだんだん気づき始めます、社内用サーバーが必要だと言うことに。
AWS上にサーバーをたてたいと思った
でもどう接続するのが安全なんだろうか。そういえばcloudpackはDirectConnectというサービスを提供しているではないか。あれを使えばVPNよりも間違いない接続が可能なのでは？いや、これはネットワークの刷新が必要かもしれない。
会社のインターネット回線を設計し直した
AWSのフルマネードサービスを提供している関係上、会社から外に出るときのIPアドレスを、お客様AWS環境のセキュティグループに追加する必要があります。東京1拠点だけならまだしも、大阪で2拠点、今後も増えたらどうする。うん、よし、閉域網にしよう。データセンターにルーター置いて、そこにデフォルトゲートウェイ向けてやればとりあえずそれっぽくなるな。
データセンターから直接AWSへ接続出来る環境が整う
全ての通信は一度データセンターに向かうようにしました。AWSへの接続もDirectConnectを通じて閉域網経由のこれまた閉域のVPCに接続される環境が整ったわけです。
要するに、旧ネットワークと、新ネットワークが混在するオフィスになる
さて、どのタイミングで切り替えようか、と思いましたが、長い時間をかけて徐々に慣らしていく（旧グローバルIPから新グローバルIPへの書き換えするなどの）方がいいなーと。だってどっちのネットワークも生きてるし、SOC2を取るといっても、業務に影響出たら元も子もないなーと思ったわけです。
ルーターやサーバーはセキュリティ的にどう設定すべきか
これはISO 27001の基準と、PCI DSSの基準を合わせて、さらにシンジがコレやった方がいいんじゃねーかという適当な思いつきルールを加えた「cloudpackセキュリティポリシー」というのを作りました。国際基準はかなり具体的な要件が求められているので、大変参考になりました。
ネットワークは一通り揃った、次は人間とドキュメント
ここで言う人間は、社内だけはなく、お客様に対しても一定の理解をして頂くことが必要になるので大変です。例えば、AWSそのもののセキュリティポリシーに対する理解度についてお客様と直接ミーティングをしたり、本番環境における作業において、必ずお客様の承認を得なければ作業に着手してはならない、という点です。これはあまりにもビジネスのスピード感が失速しかねない問題になりそうだと思い、「事前承認作業」というのを思いついて盛り込みました。予めお客様と握ってある障害対応やインシデント対応については、お客様は既に承認済みの物として、社内でのダブルチェックを行えば、本番環境を触っても良いというものです。
そして突如求められる「透明性」
これらの内容を自社Webサイトなどで公開していますか？いいえ、していません。すぐやります。 というわけで出来上がったのが、cloudpack Security White Paperです。SOC2レポートの中身をカジュアルにして、監査員のコメントを削った簡易的な内容なので、まだ未読のお客様で興味のある方は是非ご一読頂きたい内容です。
ともかく、悪意のある人間がその気になれば全て破壊出来る
それを抑制する為のシステムや、漏れの無い完全なログ（しかも見やすく追いやすく）、復旧可能かどうか（可用性）が徹底的に求められたというわけです。そういう視点で監査され、どうであったかがSOC2レポートには全て記述されています。
SOC2 レポートはNDAを結んだお客様であれば要求出来ますが
cloudpackは、誰が、いつ、誰に対してレポートを提出したか記録する必要があるそうです。レポートの取り扱いも結構厳格なんですね。しかもデジタルデータがまだ手元にないので、もしこのブログを読んだお客様がレポートみたい！ということになっても、ちょっとお時間頂きそうです（シンジの手元に冊子はあるのですが）（デジタルデータにも提出先などを埋め込む必要があるんだそうです）（確かにシンジがAWSにSOC1レポートを要求したときも結構面倒で時間もかかった記憶があります）
監査はこれで終わりません
来年の今頃は「SOC2 Type2」がどうのこうのと言っているはずです。それ以外にも沢山の外部監査を受ける予定がありますので、順次ご報告していきたいと思います。
