セキュリティは、高度な仕組みを入れることより、簡単なことを続けられるかで決まります。まずは、やめられない24項目から始めます。
使い方
各項目を「できている」「できていない」「該当しない」で埋めてください。全部を一度にやろうとせず、できていない項目に優先順位を付け、四半期ごとに再点検するのが現実的です。担当を決めていない項目は、埋める前に誰が見るかを先に決めてください。担当のない項目は、時間が経つと必ず放置されます。開発を外部に委託している場合は、自社側と委託先側のどちらが担うかも、あわせて書き込んでください。
1. アカウントと権限(5項目)
被害の多くは、高度な攻撃ではなく、アカウントの乗っ取りや、退職者のアカウントが残っていたことから始まります。人数が少ないうちは共有アカウントで済ませたくなりますが、誰が何をしたか追えなくなるため、早い段階で個人ごとに分けておくほうが、後の負担は軽くなります。人が増えてから分けようとすると、どのアカウントが誰のものかを調べるところから始めることになります。
- 共有アカウント(複数人で同じIDとパスワードを使う)をなくしているか
- 管理者権限を持つアカウントで、多要素認証を有効にしているか
- 業務委託・退職の際に、当日中にアカウントを停止する手順があるか
- 各サービスの管理者が誰かを、一覧にして把握しているか
- パスワードを、管理ツールで保管し、使い回していないか
2. 秘密情報の扱い(4項目)
APIキーやパスワードが、ソースコードやチャットに書かれたまま残っていることは珍しくありません。一度外部に出た鍵は、気づいたときには使われた後です。置き場所を決め、そこ以外には置かないというルールを先に作ってください。ルールがないまま「気をつける」だけでは続きません。過去に送ってしまった履歴が残っている場合は、鍵を作り直すところまでを、この機会に行ってください。
- APIキーやパスワードが、ソースコードに直接書かれていないか
- チャットやメールで秘密情報を送った履歴が残っていないか
- 秘密情報の置き場所(環境変数、秘密情報の管理サービス)を決めているか
- 鍵が漏れた場合に、誰がどう作り直すかの手順を知っているか
3. バックアップと復旧(3項目)
バックアップは取っているだけでは意味がありません。実際に戻せるかを一度試し、どこまで戻せるかを把握しておいてください。復旧を試したことがないバックアップは、必要な場面で使えないことがあります。年に一度でよいので、実際にデータを別の環境へ戻してみて、かかった時間と手順を記録しておくと、いざというときに慌てずに済みます。
- 顧客のデータのバックアップを、自動で取得しているか
- バックアップから復元する作業を、実際に試したことがあるか
- どの時点まで戻せるか、復旧にどれくらいかかるかを把握しているか
4. 個人情報の棚卸し(4項目)
自社がどんな個人情報を持っているかを一覧にできない状態は、それ自体が問題です。項目と利用目的を書き出してみると、実は使っていない情報を集めていたことに気づくことがあります。取得しない情報は、漏れることもありません。委託先については、開発会社だけでなく、メール配信や分析などの外部サービスも対象になりますので、あわせて書き出してください。
- 取得している個人情報の項目と、その利用目的を一覧にできるか
- 取得しているが使っていない項目はないか(あれば取得をやめられるか)
- 個人情報を渡している委託先(開発会社、外部サービス)を把握しているか
- プライバシーポリシーの記載が、実際の取り扱いと合っているか
5. システムの継続的な手当て(4項目)
作った時点で安全だったシステムも、時間が経てば、使っているライブラリに問題が見つかります。人手で追い続けるのは難しいので、自動で検知する仕組みを一度入れておき、通知の宛先を決めてください。通知が誰も見ない場所に届いている状態は、入れていないのとほとんど変わりません。開発を外部に委託している場合は、この部分が保守契約に含まれているかを確認してください。
- 依存しているライブラリの脆弱性を、自動で検知する仕組みがあるか
- 検知の通知が、実際に読まれる場所(担当者のチャットなど)に届いているか
- 通信が暗号化されているか(HTTPS)。証明書の期限切れを検知できるか
- 管理画面が、インターネット全体に公開されたままになっていないか
6. 生成AIツールの利用ルール(2項目)
生成AIのツールは業務に広く使われるようになりましたが、入力した内容がどう扱われるかはサービスごとに異なります。顧客の個人情報や、秘密保持の対象となる情報を入力してよいかは、使う前にルールを決めておく必要があります。全面的に禁止にすると、結局は各自が個人の環境で使うことになりがちですので、入力してよい範囲を決めて明示するほうが、実際には守られます。
- 入力してよい情報と、入力してはいけない情報の線引きを決めているか
- 業務で使うツールを把握し、それぞれの入力データの扱いを確認しているか
7. インシデントの初動(2項目)
何かが起きたとき、最初の数時間に何をするかを決めていないと、対応が遅れ、被害が広がります。手順は長い文書である必要はなく、1枚で足ります。連絡先と、最初にやることだけでも書いておいてください。特に、状況が分からないうちに慌てて外部へ告知したり、逆に調査だけを続けて連絡が遅れたりすることを防ぐため、誰が判断するかを先に決めておくことが重要です。
- 情報漏えいや不正アクセスが疑われたとき、最初に誰に連絡するかを決めているか
- 対応の手順(記録を残す、影響範囲を確認する、外部への連絡を検討する)を1枚にまとめているか
点検を続けるために
24項目のうち、できていないものが多くても問題ありません。重要なのは、次の四半期までに、できていない項目を何個減らすかを決めることです。点検の日をあらかじめカレンダーに入れ、前回のシートと並べて比べると続けやすくなります。開発を外部に委託している場合は、この資料をそのまま渡し、どこを相手が担い、どこを自社が担うかを分けて確認してください。
- 次回の点検日をカレンダーに入れたか
- できていない項目のうち、次に着手する1〜3項目を決めたか
- 各項目の担当者(自社側・委託先側)を書き込んだか
- 前回のシートを保管し、比べられるようにしているか
ご注意
この資料は一般的な情報を整理したものであり、法的な助言ではありません。個人情報保護法をはじめとする法令上の義務や、漏えい等が起きた場合の報告義務の要否、業種ごとの規制については、弁護士などの専門家にご確認ください。医療・金融をはじめ、追加の規制がある領域では、この24項目では足りない場合があります。また、自社に合った対策の水準は、扱うデータの性質と事業の規模によって変わります。
関連するインサイト
- スタートアップのセキュリティと個人情報保護 — 最低限の実務スタートアップが最低限押さえたいセキュリティと個人情報保護の実務を、アカウント管理や秘密情報の扱い、個人情報の取得と削除、CI/CDへの検査組み込み、インシデント初動、生成AI利用の注意まで整理します。
- 資金調達前に整えておきたいプロダクトと技術面の準備投資家による技術デューデリジェンスを見据え、資金調達前に整えておきたい準備を手順化。プロダクトの現状説明資料、指標の整理、技術的負債の可視化、セキュリティと個人情報の基本対応、ソースコードの権利、開発体制の説明を解説します。
- 生成AIを開発工程に組み込む — 品質を落とさず速く安く作る実務設計書の下書き、コード生成とレビュー、テスト生成、既存コードの解析、ドキュメント整備での生成AIの使いどころと、人がレビューする原則、顧客データや秘密情報の扱い、向く作業と向かない作業を整理します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開