シンジです。セキュリティについて高い関心があり、自社のサービスを内外からも一定の基準を用いて証明したいと考える場合、PCI DSS認証の取得は大変良い候補となります。cloudpackは3年連続の監査を受けていますが、シンジはPCI DSS管理責任者を兼任しているので、どうやって認証を取得するのか書けるだけ書きます。
PCI DSSを取得するメリット・デメリット
あなたにとってセキュリティとは何ですか？
視点を変えると、如何様にも解釈出来る便利な単語ですよね。シンジは「透明性」だと最近は思っています。なので、全面ガラス張りの部屋で仕事をさせるようにしています（冗談です）
セキュリティには、「一定の基準」が必要です。その基準をかなり踏み込んで具体的に提供してくれるのがPCI DSSなのです。 よく聞くのが、
「クレジットカードの様な情報を取り扱わないけど、PCI DSSって取る意味あるの？」
という話です。これは、
「ウチのセキュリティは、クレジットカードの様なセンシティブな情報さえも取り扱えるだけの体制があることの証明なんですよ」
ということですから、十分な効果が期待出来ます。（厳密にはイコールではありませんが、平たく書くとこんな感じです）
PCI DSSを取得するデメリットもあります。それは、
- なんとなく監査日が近づくとそわそわする（かもしれない）
- 監査員のお弁当とか用意した方がいいのかなとか悩む（別にいらない）
- 監査日前日あたりからなんかピリピリし始める（という人もいるかも）
そう、デメリットなんぞございませんよ。いいことだらけです。会社も担当者も大変勉強になりますし、例外を除きますが、監査員の方は手取り足取り教えてくださいます。
PCI DSS監査の特徴的な点
それは、「指摘されたらその場で速攻直せば通せる」点にあります。
いくつか例をあげましょう。
監査員「このレビュー記録、見せて頂けますか？」
担当者「あーえーあーえーうー、2時間ください（つくろう。。。）」
これでいけます。
監査員「あら、ここのNTP設定が間違えてますねぇ」
担当者「あ、ほんとだ。じゃあいま直しますね」
これでいけます。
監査員「では今日はこれで終了にしましょう、残課題は2件でしたね」
担当者「2件ですね、今日中にメールで記録送ります」
これでいけます。
PCI DSSの監査では、「無いものは無い、出来ていないものは出来ていない、それは仕方の無い事、じゃあこれからどうするか決めちゃおう、一緒に考えましょう」という点にあります。ですから、これから監査にチャレンジされる方は、
「どうせウチのセキュリティじゃ監査通らないよなぁ。。。」
なんて思うかもしれません。
はい、まず通りません。だがしかし！
国際基準であるPCI DSSに乗っかりたい意思があるのかどうか！必要なのはそこです。
お金はいくらかかるのか
結論から言うと、そこそこかかりますが、規模と範囲によります。また、インフラ整備にかかるコストもあるかもしれません。全く未知からのチャレンジの場合、多くはコンサルを入れますから、この費用もかさみます。
数十万で終わるケースは、可能性は別として、ほとんど無いでしょう。まずは百万単位と考えてよいと思います。
セキュリティにはお金がかかるのです。
が、明確な基準への投資としては、費用対効果も明確な投資と思います。
監査をする上で、有利なケースと不利なケース
優劣を付ける為に有利不利と書きましたが、実際不利なケースはありません。それは以下の有利なケースを見ることで分かります。
- クレジットカード番号を取り扱わない場合
- 会社の中でも特定の場所や機材に絞って監査をする場合
- ネットワーク機器が企業用製品で統一されている場合
これの逆が不利なケース、というより、単純に確認事項が多くて大変だという話です。
- クレジットカード番号を完全に取り扱っている場合
- 監査範囲を全社内に適用させたいと考えている場合
- ネットワーク機器が家庭用だった場合
クレジットカード番号を取り扱うと言うことは、Webアプリケーションやデータベースを保有しているということになりますから、これらの状態や脆弱性、侵入テストの結果などを徹底的に求められます。
また、監査範囲を全社に広げた場合、単純に物理アクセスでのネットワークアクセス経路が増えますから、監査も大変だということです。無線LAN使ってたら、もう発狂ものです。
最後のネットワーク機器は、機器のメーカーや機種は何でもいいのですが、IPとポート単位でアクセスの制御ができるかどうか、ルールセットが書けるかどうか、コンフィグがバックアップできて切り戻しできるかどうかなどが問われますから、家庭用だとしんどい可能性があります。
監査項目は12の要件からなる400項目以上
まずどんな項目があるかというと、実はWebで全て公開されています。日本語版は現時点ではv3.0のものしかありませんが、非公式ではあるもののv3.1の追加項目を日本語化してくれているWebサイトもあるので、合わせて見ることで全要件を確認出来ます。
https://ja.pcisecuritystandards.org/onelink/pcisecurity/en2ja/minisite/en/docs/PCI_DSS_v3.pdf
このv3.1要件の中で、「絶対やってくれ」という項目と「やった方が良さそう」という項目の2つに分かれます。基本的に「やった方がよさそう」な要件はすきっぷされますが、バージョンが上がった際にはその項目が「絶対やってくれ」に格上げされます。
監査手順とスケジュール
基本的にはコンサルにお任せしましょう。コンサルが予め状況を確認して、監査日程の調整および、どんな監査になりそうかの調整を監査団体とあれこれしてくれる場合があります。
既に社内に精通した人がいる場合は、早々に監査依頼をかけても問題ありませんが、それでもシンジはコンサルに依頼することをオススメします。何故ならば、
- 監査を受ける会社の事情を伝えてくれる（かもしれない）
- 予めコンサルが模擬監査した内容で調整してくれる（かもしれない）
- 監査当日も付き添って、フォローしてくれる（かもしれない）
監査員とコンサルは事前のコネクションがある場合がありますから、これを活用するわけです。
そして、どうやって監査していくのかというと、要件1.1から順に400以上に及ぶ全ての項目をひとつひとつ監査員が解説を交えて、書類の確認をしたり実機の確認をしたりしていきます。この監査中、全ての担当者がその場にいる必要はありません。また、不明な部分は後回しにもできます。そして必殺の、
「対象外」
という手が使えます。これは、「この要件は、これこれこういう理由だから、対象外ですね」と監査員が判断すれば良いわけです。ここで事前のコンサルが重要になります。というのも、これこれこういう理由だから、この辺りは対象外になると思います、というのを事前にやっておいてくれる場合があります。これがあると、監査の効率がグッと高まりますし、正確性が増します。
さらに必殺、
「代替コントロール」
という手が使えます。これは何かというと、
業務の都合で遵守が厳しい、だからそのままにしたいので、その項目を補う形でシステムや人員、ルールの整備をすることでOKにしてもらえませんか？ということです。これは結構使えます。実際運用上どうにもならない点というのがあるわけで、業務効率が著しく落ちてしまうとか、業務に影響が出てまで監査を続けるのは本末転倒ですから、ほとんどの監査要件において、この「代替コントロールが」適用可能となっています。詳しくはv3.0のPDFの109ページ目以降を参照下さい。
監査前に準備しておくこと
これはもう、
監査項目を証明する準備
これに限ります。課題管理ツールなどを利用して、要件を課題として担当者を決めましょう。担当者という意味合いで言えば必要なのは、
- PCI DSSシステム運用担当者
- PCI DSS管理責任者
この2名は最低でも必要です。組織的には、運用担当者がシステム変更依頼を出して、管理責任者が承認するという流れを組みます。
また、IPS/IDS, WAF, アンチウィルス, ログ管理及び監視などなど、PCI DSSのとある要件をクリアするために開発された有償ソフトウェアが数多く存在していますが、その多くは購入する必要無くOSSのみでも監査を通せます。実際そうしたことがありますし、監査員もコンサルも十分理解しています。ただしcloudpackの場合、IPS/IDSをOSSで用意出来なかった為、トレンドマイクロ社のDeep Securityを導入していますが、別にこれに限る必要はありません。
ぶっちゃけもっと言えば、cloudpackではIPS/IDSが存在しない状態で監査を受けて、指摘されてその場でセットアップするという経緯もあったくらいです。良く言えばそれくらい柔軟な監査を受けることが出来ます。
これ以上無いくらい十分な準備と臨戦態勢で望む必要はありません。監査項目で分からないところがあれば、監査中に聞いてみましょう。それで良いのです。
監査中に必要な事
全ての担当者が監査日程の間は出社するようにしましょう。監査日程は規模によっては2日〜3日で終わることもあるかもしれませんが、2週間とか言われる可能性もあるかもしれません。どちらにしても、関係者は全員会社にいるようにしてください。先ほども書きましたが、全員が監査に出席し続ける必要はありません。必要に応じてバトンタッチしながら、また、指摘された項目を修正しながら対応します。
実機監査の際に、事前に準備していた関係者以外の社員にインタビューされることがあります。例えばPCI DSSへの理解度はどうでしょうかだとか、キャビネットの鍵はどう管理されているのですかとかです。いじわるな質問をするわけではありませんが、予定外の事になるので、ちょっとビックリしてしまうかもしれません。まぁ、そんなもんなので、あまり気にせず普通に答えて頂ければ良いと思います。状況がひどければ、指摘が入って修正すればいいだけの話ですから。
監査後に必要な事
監査日程を全て完了して、「検出事項はありません」とされれば、あとは監査員が作る監査報告書（ROC）、準拠証明書（AOC）が送られてくるのを待ちましょう。AOCには社長もしくはそれ相応の人間のサインが必要で、これを返送しなければなりません。
検出事項がある場合、先1ヶ月以内にその課題を解決する必要がありますが、基本的にはエビデンスの提出をメールで行えばOKです。あまりにも検出事項が多いとか、特段の事情があれば、再度監査が入りますが、滅多にありません。残りの検出事項のエビデンスが受理されれば、そのタイミングから先方がROCとAOCの作成を開始します。
PCI DSSに準拠したと発表出来るタイミング
監査員と社長のサインが入った書類が揃ったタイミングが、発表出来るタイミングになります。
最も重要なこと「継続監査を受けること」
PCI DSSの監査が終わった後、次に監査を受けるタイミングは、
- 1年後の同じ時期
- 大きなシステム変更などがあった場合
です。監査は最低毎年必要です。どちらにしても「届け出」が必要です。そして、継続監査だからといって、既に監査済みの項目をスキップすることは一切ありません。また1から全ての項目を監査します。そしてPCI DSS基準もどんどんバージョンアップしていきます。従って、
前回監査時に決めた運用が、PDCAサイクルで回ってるか評価されるため、継続監査の方が圧倒的に大変です。
例えば、毎日ログレビューしますだとか、4半期に1回脆弱性テストしますだとか、1年に1回侵入検知テストしますだとか、そーゆーもののエビデンスが求められます。
経験上、PCI DSSの維持で最も大変なのは運用と継続監査です。はっきりいって、取るだけならほとんどの会社さんが取れると思います。取りました！だけで終わらず、1年以上継続しているかが、本当の意味でのPCI DSSを運用出来ているかが問われます。なのでシンジは個人的には、PCI DSSを取得したばかりの会社は余り信用しておらず、1年以上（1回以上の更新が）出来ている会社かどうかを見るようにしています。
余談ですがcloudpackの検出事項修正速度は史上最速らしいです
監査員がウチのスタッフの対応速度が速すぎて驚いていました。「そんなに急がなくても大丈夫ですよ」と遠慮されるという。別に急いでいるわけでは無くて、染み付いているんですねたぶん。出来れば言われる前に、もし言われたら速攻でなんとかしたいというスタイルが。。。
というわけでこれからPCI DSSを取りたいと言う方
よーわからんけど予算とやる気は何とかする、という方はシンジまでご連絡頂ければいろいろご紹介出来ますので気兼ねなくご連絡下さい。一丸となってIT事業のセキュリティレベルをどんどん高めていきましょう！
