情報セキュリティポリシー
読み: じょうほうセキュリティポリシー
情報セキュリティポリシーとは
情報セキュリティポリシーは、組織が保有する情報資産をどう守るかを体系的に定めた方針・規程の総称である。技術的な対策だけでなく、人の行動規範や組織体制、インシデント発生時の対応手順までを包括する。経営層の承認を得て全社に適用されるこの文書が、情報セキュリティの起点になる。
かんたんに言うと
会社の情報を守るためのルールブック。「何を」「誰が」「どう守るか」を明文化し、全員が同じ基準で行動できるようにするための土台である。
基本方針から実施手順まで三層で構成される情報セキュリティポリシーの全体像
情報セキュリティポリシーは一枚の紙ではない。一般的に三つの階層で構成される。
最上位に「基本方針」がある。経営者が署名し、情報セキュリティに対する組織の姿勢を宣言する文書で、数ページ程度の短いものが多い。
次に「対策基準」。基本方針を実現するために、ネットワーク管理やアクセス制御、外部委託先の管理など、領域ごとの具体的なルールを定める。
最下層が「実施手順」。対策基準を現場の作業レベルに落とし込んだマニュアルである。パスワードの文字数や更新頻度、USBメモリの持ち出し申請フローといった細かな手順がここに書かれる。
とはいえ、三層をきれいに分けている組織は意外と少ない。基本方針と対策基準が一体化していたり、実施手順が各部署に散在していたりするケースは珍しくない。
策定の進め方と経営層の関与
策定プロセスで最初にやるべきことは、守るべき情報資産の洗い出しである。顧客データ、設計図面、人事情報、財務データ。どこに何があるかを把握していない状態でポリシーを書いても、穴だらけの文書ができあがる。
情報資産を特定したら、リスクアセスメントに移る。資産ごとに「漏洩した場合の影響」と「漏洩が起こる確率」を評価し、優先順位をつける。全てを同じ強度で守ることは予算的にも運用的にも不可能だからである。
ここで経営層の関与が不可欠になる。セキュリティ投資の意思決定は現場では下せない。「この情報が漏れたら事業が止まる」というリスク判断は、経営判断そのものにほかならない。
総務省が公開している「情報セキュリティポリシーに関するガイドライン」は、策定手順の参考になる。ただ、ガイドラインをそのままコピーしても自社に合ったポリシーにはならない。自社の業態、規模、リスク特性に応じた読み替えが求められる。
<a href="/ai-glossary/isms/">ISMS</a>認証との関係
ISMSはISO/IEC 27001に基づく情報セキュリティマネジメントシステムの国際規格で、情報セキュリティポリシーはその中核に位置する。ISMS認証を取得するには、ポリシーの策定はもちろん、PDCAサイクルによる継続的改善の仕組みまで求められる。
認証取得が目的化してしまうケースは多い。審査を通すためだけに形式的な文書を整え、現場では誰も読んでいない。これでは事故が起きたときに機能しない。
認証の有無にかかわらず、ポリシーの中身が実態と合っているかを定期的に見直す運用こそが本質である。年に一度の内部監査で形骸化を防ぐ組織もあれば、インシデント発生をトリガーに随時見直す組織もある。
AI時代に追加すべき項目
従来のポリシーはサーバーやPCを前提に書かれている。ところがいま、社員が業務でLLMを使い始めている。ChatGPTに社内の議事録を貼り付けて要約させる行為は、情報の外部送信にあたる。従来のポリシーではこの行為を明確に禁止も許可もしていないケースが多い。
追加すべき項目は少なくとも三つある。
まず、生成AIへの入力データの取り扱いルール。機密情報をプロンプトに含めてよいか、含める場合の条件は何かを定める。次に、AI生成物の利用ルール。AIが出力したコードや文書の著作権リスク、正確性の検証義務を明記する。そして、シャドーAIの検知と管理。IT部門が把握していないAIツールの利用は、シャドーITと同じ構造のリスクを持つ。
ポリシーは一度作って終わりではない。技術環境の変化に合わせて更新し続ける必要がある。AI活用が進む組織ほど、このサイクルを速く回すことになる。
形骸化させないための運用設計
セキュリティポリシーの最大の敵は、作った本人以外が読まないことである。
対策として有効なのは、ポリシーの内容を日常業務に埋め込むことにほかならない。たとえばファイル共有時にポップアップで注意喚起を出す、メール送信時に添付ファイルの暗号化を自動適用する、といった技術的な仕組みで行動を誘導する。
教育も欠かせない。ただし年に一度の座学研修だけでは記憶に残らない。短い動画やクイズ形式のeラーニングを四半期ごとに実施し、直近のインシデント事例を題材にするほうが実効性は高い。
違反があった場合の対応フローも事前に決めておく。懲戒処分の基準を曖昧にしておくと、いざというとき対応が遅れる。一方で厳しすぎる罰則はインシデントの隠蔽を招く。報告しやすい空気をどう作るかまで含めて、ポリシーの運用設計と考えるべきである。
当社の見解
当社はAIの安全運用のために3層防御を設計・実装している。万が一インシデントが発生しても数分以内に復旧できるバックアップ体制を持つ。実際にAIが暴走してテスト環境を停止させた経験があり、その教訓から「失敗を防ぐ」だけでなく「失敗しても戻せる」設計が本質だと確信している。加えて、AIは事実でないことを断定する。この前提で事実/推測の強制分離とファクトチェックを実装した。安全性は仕組みで担保するものだ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。