How do you like セキュリティーチェックシート ?
ちゃーんちゃちゃちゃちゃちゃらららーん、ちゃららー、ちゃーん、ちゃらららー （オープニング曲、開会式斉唱終わり）
セキュリティーチェックシートとは
セキュリティーチェックシートとは、ある企業がIT関連のなにかを発注する(契約する)ときに、発注先企業のセキュリティーの状況や対応を記載させるものです。 （もっと一般的な意味で、何かの組織・システムのセキュリティー面をチェックするための項目が並んだシート、という意味もありますが、このページではBtoB契約前提で書きます）。発注内容・契約形態・案件規模にもよりますが20～500項目くらいあります。それら項目について「Yes(はい)」「No(いいえ)」「N/A(対象外)」を発注先企業が記載し、発注元企業に回答します。
ただ、記載するだけではなく「発注するに Yes であることが必須、その項目が No または N/A である場合は、しかるべき理由を書くこと」といった項目もあり、項目の多くが満たせない場合や理由が受け入れられない場合、その受注はなしになる場合もあります。これは相手の要望を満たせないので致し方ありません。
例としては
| No. | カテゴリ | チェック項目 | 基準 | Yes | No | N/A | 備考 |
|---|---|---|---|---|---|---|---|
| 1 | アプリケーション | 入力された項目のサニタイジング | サニタイジングが必要な文字「&<>"'」が入力されたときエラーとするか変換していること | ||||
| 2 | ミドルウェア | データベースを暗号化しているか | システムの求めに応じデータベースを適切に暗号化する | ||||
| 3 | システム構成 | 使用する各端末にウイルス対策ソフトは導入されているか | 使用する全端末にウイルス対策ソフトが導入されていること | ||||
| 4 | 物理的環境 | 情報の保存先は日本国内のみかどうか | パブリッククラウドを含め弊社が転送した情報が日本国内にのみ保管されていること |
といった感じです。（この例、下で問題例として取り上げるため、実はおかしなチェック内容にしています。）
"No.～基準"までがシートに記載されていてます。回答する発注先企業は"Yes,No,N/A"を3択で✅をつけ、備考欄にNoやN/Aの理由のほか、注記を記載できます。こういう項目が20～500項目あるExcelのシートに、発注先企業の回答担当は自社の状況、対応を確認しながら、ひたすら記載してゆくわけです。
知ってる人は知っているが、知らない人はぜんぜん知らない
最近参加したエンジニアがぞろぞろいらしたカンファレンスで、私が
「……あの セキュリティーチェックシート ってあるじゃないですが、あの 面倒なアレ です。アレにこの規格を採用するよう書いてあったら、各企業に規格の採用が広がるかもですね。あはは。」
と話したことがありました。その瞬間、
- 嫌なことを思い出したのか顔を曇らせたり苦笑いをするエンジニアの方々
- なにそれ？チェックシート、セキュリティー……と頭の上に？があるエンジニアの方々
ときれいに分かれていました。前者が3分の1、後者が3分の2くらいだったでしょうか。企業向け商売な会社でお客様よりの仕事をするエンジニアは携わったことがあり、その辛苦を思い出したエンジニア勢が3分の1なのだと思います。
セキュリティーのためとはいえ、その対応には多大なリソースが費やされています。日本国内の各企業から発注を受ける各企業ではこの対応リソースの発生が問題視されています。半年前こんなツイートがありました。
では、なぜ
- このセキュリティーチェックシートの対応、時間がかかるのか？
- 自社の状況、対応を記載するだけなのに、なぜ労力を要する羽目になるのか？
そのような 闇 と、（ 敵 発注元企業は強大で歯が立たないかもですが） 防衛術 を書いてみました。私はこのセキュリティーチェックシートを回答する側（発注先企業、受注側）なので回答することを闇としてこのエントリを書いています。
（いつもながら前置きが長い、すみません。）
闇その1 各社秘伝のたれである
まず、このセキュリティーチェックシートは統一されておらず、 各社が各々に自社のセキュリティーチェックシートを持っています。 そのため、発注間近になって、発注元→発注先へセキュリティーチェックシートが送られたとき、発注先＝受注する側としては、 各お客様で毎回異なるチェック項目が並んだセキュリティーチェックシートを受け取り回答する わけです。
「プライバシーマーク(JISQ15001:2006、個人情報保護マネジメントシステム)」とか「JISQ27001(ISMS、情報セキュリティのマネジメント規格)」とかすでにありますよね。それを発注先が持っていれば、そのセキュリティーチェック飛ばしていいんじゃないの？
という疑問があると思います。これら、プライバシーマークやJISQ27001取得は、どちらかというと、発注元が発注先企業をふるいに掛けるために使用されていて、プライバシーマークやJISQ27001を取得しても、当然のごとくセキュリティーチェックシートは 送りつけられてきます 送られてくるので回答します。
そのような各社バラバラのセキュリティーチェックシートにも、元ネタは存在しています。
- SaaS 向け SLA ガイドライン（経済産業省） ※元ページが消えてる
- クラウドサービス提供における情報セキュリティ対策ガイドライン（第3版）（総務省）
- 安全なウェブサイトの作り方（IPA）
あたりでしょうか。これらと自社のアクシデントやヒヤリハットを発注先企業のセキュリティー担当者が ごちゃ混ぜ 統合したものが、各社のセキュリティーチェックシートとしてできあがります。そして自社や他社の事故例を元にセキュリティーチェックシートの項目は増えて行き（減りはしない）、担当が変わったりして、
- 項目はなんだかたくさんある
- 全体的な考え方は読み取れない
- なぜその項目があるのか根拠が分からない
- 項目の意味が分かりづらい
「各社秘伝のセキュリティーチェックシート」 ができあがります。受注する側（ここにはSIの受託もSaasなサービス提供も業務委託もすべて含みます）は毎回この異なるセキュリティーチェックシートが来るたび、頭を捻らせながらせっせと回答するわけです。
闇その1「各社秘伝のたれである」への防衛術
防衛術としては3つあると思います。
- 各社からの依頼を受け回答する（商慣習上必要）。回答しない企業も多いので回答することは隠れた売り文句である。その分、組織内ではセキュリティーチェックシート回答に一定のリソースを割くことを組織全体の方針・前提とする。←片手間ですると担当が過労死する
- 回答を有料の事項とする(受託ならその分見積金額増加、Saas提供ならオプション扱い)。こうすればセキュリティーチェックシートを無闇に受け取り回答することはなくなる。（有名どこの例、えーとこれ → Backlog - セキュリティに関する書類に回答を記入してもらえませんか？ ）
- 突っぱねる。クラウド大手はこれですね（自分の知る限りでは）。その分、サイトでセキュリティーに関する情報を開示し、発注する側が発注先のセキュリティーはどのようになっているのか判断できるようにする必要がある。
闇その2 契約内容やサービス形態を反映していない
セキュリティーチェックシートでは
- Saasでのサービス提供をするのに、発注元・発注先間での業務委託を前提としたセキュリティーチェックシートが送られ回答が求められる
- 開発のみを請け負い、個人情報の授受はないのに、運用時のサービス提供体制や個人情報の扱いに関しての記載が大半を占めるセキュリティーチェックシートが送られ回答が求められる
なんてことが、しばしば発生します。例えですが
- Saasでサービス提供する会社(またはサービス担当部門)に、いきなり業務委託の見積を依頼する
- システムインテグレーション(SI)を行う会社に、よそのつながりない会社のSaasの見積を依頼する
なんてことは通常ありませんよね。しかし、 セキュリティーチェックシートでは契約する内容と異なる事柄について回答を求められることがあります。
これは、発注元企業の
- 発注する元の業務と直接関係ないセキュリティーの担当部署がセキュリティーチェックシートをどの用途でも一つで済ませようとする
- 発注する部署はとにかくセキュリティーの担当部署から了承を得たいので、そのまま発注先企業へ転送
という構造で発生するものと 考え 憶測しています。絵にするとこうです。
典型例が上であげた
| No. | カテゴリ | チェック項目 | 基準 |
|---|---|---|---|
| 3 | システム構成 | 使用する各端末にウイルス対策ソフトは導入されているか | 使用する全端末にウイルス対策ソフトが導入されていること |
を「ブラウザベースなSaasを提供する組織が回答するケース」です。
まず、"使用する端末"という表現が謎です。ブラウザベースなSaasなら端末は、セキュリティーチェックを依頼したサービス提供先＝発注元企業のPCなりスマートフォンです。発注先が答える事項ではありません。"使用する端末"を" Saasを提供する組織が維持管理をするために 使用する端末(PCやスマートフォン)"と拡大解釈するとチェックする意味が分かりますが、拡大解釈すぎやしないか？と回答側は思うわけです。 （ 多くの場合、発注元が書いてほしかったことは後者の拡大解釈の方です 
。）
もう一つ例をあげると上であげたこちら
| No. | カテゴリ | チェック項目 | 基準 |
|---|---|---|---|
| 1 | アプリケーション | 入力された項目のサニタイジング | サニタイジングが必要な文字「&<>"'」が入力されたときエラーとするか変換していること |
を「CMS(WordPress)とかECサイト(EC-Cube)で構築し納品する際に、HTMLのタグを流し込む管理画面にまで、このチェックを満たすことを強要されるというケース」です。Yesにし対応すればHTMLのタグが流し込めないのでCMSでのサイト運営やECサイトの運用ができません。これを発注元企業の担当者と話せば、 「えーと、なんとかYesにならないですか～」「いやー（心の声：なるか💢）」 と不毛なやり取りが積もったりするわけです。
（※この基準は過去見聞きしたおかしいものを使っています。「&<>"'」のサニタイジングは入力するときではなく出力するときでしょ、ってのはその通りです。）
闇その2「契約内容やサービス形態を反映していない」への防衛術
この闇その2は、発注先企業が発注内容・契約と異なる意味のないセキュリティーのチェックをさせることに端を発しています。この闇への第1選択薬は
- 突っ返す。 そもそも回答するにあたらないものとして N/A（該当しない）で埋めて返す
です。そうすると、発注先企業の発注に直接携わる担当部署とセキュリティーをチェックする部署で「たしかにこの○○に、当社のセキュリティーチェックシートをそのままあてはめても❌だ。N/A受け入れよう or 契約内容に沿ったセキュリティーチェックシートを作って送ろう」となります。
しかし、 敵もさるもので発注先企業が「たしかにこの○○に、当社のセキュリティーチェックシートをそのままあてはめても❌だ。しかし当社としても当社のセキュリティーチェックシート様を変更する事は罷り成らぬ。なんとか言いくるめられるよな作文をしてくれ（意訳）」と返されることもあります。そのような場合の第2選択薬は
- 備考に回答をYesにするため解釈を変更したことをきっちり記載する
です。例えば上のNo.1なら備考欄に「エンドユーザーに公開する画面が対象。貴社のみ使用する管理画面はHTMLのタグが流し込む必要があるため、この事項の範囲外とする」と書いて回答します。これはその発注元と後々お付き合いが続き、お互いの担当者が変わった際、過去の不明なやり取りにしないためです。（そのようなお客様から受注するのが適切かは別途考える必要があると思います。）
闇その3 何を求めてるのか分からない項目が多い
具体例から入ってみます。
| No. | カテゴリ | チェック項目 | 基準 |
|---|---|---|---|
| 2 | ミドルウェア | データベースを暗号化しているか | システムの求めに応じデータベースを適切に暗号化する |
この例No.2をDBMSを提供するPaasの立場でセキュリティーチェックシートに回答すると、こんなやり取りが 生まれたりします 生まれるかもしれません。
「暗号化」だけだと何をセキュリティーの要件として求められているか分からない 、ということです。良い意味に取ると、実現方法は発注先企業に委ねられているという解釈もできます。Yesに✅し備考欄に「弊社では○○でデータベースの暗号化を実現しています」と回答してOKになればよいのですが、そもそも暗号化で達成したいセキュリティー要件が何か発注元企業でも分からなかったりすると、上の画像のような不毛なファイトが生じます。
もう一つ例を
| No. | カテゴリ | チェック項目 | 基準 |
|---|---|---|---|
| 4 | 物理的環境 | 情報の保存先は日本国内のみかどうか | パブリッククラウドを含め弊社が転送した情報が日本国内にのみ保管されていること |
この例No.4をECサイトの作成サービスを提供するSaasの企業(例：BASE, STORES, Yahooショッピング……)の立場で答えたとします。
- AWSでRDS(DBMSのサービス)＋EC2上のVMインスタントでアプリケーションを動かす構成。このとき東京リージョンを指定。
- AzureでAzure SQL＋Azure VMでアプリケーションを動かす構成。このとき東日本リージョンを指定。
- 自社で日本国内のデータセンターと契約しそこに各サーバーを用意してサービス
いずれの構成を取っても、ECサイトを設置する企業(発注元)に対し、発注元から直接来る情報(商品マスタとか)もインターネットからユーザー登録・注文を受け付けたエンドユーザーの情報(顧客マスタや注文履歴とか)も、国内のデータセンターに保存されます。しかし、ここに画像の転送量を押さえるためCDNを使用した場合、CDNは海外におかれたCDNのエッジサーバーにもキャッシュされるので「お客様企業から受け取った商品画像という情報が日本国外にある」となります。かといって、商品など各画像についてCDNを使用しないのも現実的ではありません。
そんなふうにして、そもそも 「情報」って一体何を指すんだ？曖昧じゃないか 、とセキュリティーチェックシート担当は頭を抱えることになるわけです。現実的には、
「情報」の対象からサイトのバナー画像や商品画像のような広く公開される画像ファイルは、このNo.4の対象外とする、
といった合意が発注元企業と発注先企業間で成り立った上で、Yesに✅し備考欄に注記を書くことになります。
闇その3「何を求めてるのか分からない項目が多い」への防衛術
闇その3も地味に多いパターンです。この闇は発注先企業＝注文を受ける側がそのサービスや契約内容に沿って、
- この○○は今回の××から◇◇と捉えました。だからYesに✅です
- この○○は今回の××から◇◇と捉えました。だからNoに✅です
- この○○は今回の××から◇◇と捉えました。だからN/Aに✅です
と解釈を明記し回答することが防衛術だと思います。（個人的には、 このような何を言っているか分からない事項に注記して解釈を明確にすること、日本語解読大会、と呼んでます。 ）
特に項目が多いとき、どうしようにも解釈のできない/何を求めているのかサッパリ分からない項目がセキュリティーチェックシート上に発見されるときがあります。そういうものは、発注元企業に「この項目は一体何か？」と聞いて、回答できる問いになってから回答する必要があると思います。
今回も長くなってしまいました。うーん、文章を短くまとめるのは難しい。指摘あればコメントやTwittwerなどでご指摘いただけると幸いです。