皆さん、こんにちは！開発現場やインフラの裏側で、日々システムを守る奮闘をしている新人のIT担当者さん、そしてセキュリティに初めて触れる開発者の皆さん。セキュリティの世界へようこそ！
「ISO/IEC 27001」とか「附属書Aの管理策」なんて言葉を聞くと、なんだか分厚い英語の取扱説明書を読まされているようで、頭がクラクラしてしまいますよね。「セキュリティのルールって、なんだか堅苦しくて開発の邪魔になりそう…」なんて感じることもあるかもしれません。
でも、安心してください。セキュリティの国際標準であるISO/IEC 27001がやろうとしていることは、私たちが普段の生活でやっている「戸締まり」や「貴重品の管理」とまったく同じなんです。
今回は、難しい専門用語をいったん脇に置いて、身近な防犯の例えを交えながら、リスクアセスメントと附属書Aの管理策をどうやって日々の開発やインフラ管理に結びつけるのか、一緒に優しく紐解いていきましょう！
—
1. 家の鍵と泥棒に例える「リスクアセスメント」の基本
まずは「リスクアセスメント」という、ちょっとカッコいい名前の仕組みからお話ししますね。
想像してみてください。あなたは新しく一軒家を買いました。この家には、あなたの宝物である「大切なデータ（顧客情報やソースコード）」がたくさん詰まっています。さて、あなたはこの家を泥棒から守るために、どうしますか？
いきなり「最新型の防弾ガラスを入れよう！」「24時間体制の警備員を雇おう！」と予算を使い果たすのは、ちょっと待った！ですよね。まずはこう考えるはずです。
1. 我が家のどこに、どんな弱点（脆弱性）があるだろう？（例：玄関の鍵は古いけど、勝手口の鍵は頑丈だな。でも、2階の窓は夜も開けっぱなしにしがちだな、など）
2. どんな泥棒が、どこから狙ってきそうだろう？（例：プロの空き巣なのか、うっかり鍵をかけ忘れた隙を狙う通りすがりなのか）
3. もし入られたら、どれくらいの被害が出るだろう？（例：リビングのテレビ盗まれるくらいなら痛いけど、通帳と印鑑が置いてある金庫が開けられたら人生が終わる…！）
この「我が家の弱点を見つけて、どこを重点的に守るべきか優先順位を決める作業」こそが、まさにセキュリティで言う「リスクアセスメント」なんです。
ITの世界でも同じです。「うちのシステムにはどんなデータがあって、どこから侵入されるリスクがあるのか」を洗い出し、「もし破られたらどれくらいヤバいか」を評価する。これがすべてのセキュリティ対策のスタートラインになりますよね。
—
2. 附属書Aの管理策ってなに？（＝ホームセンターの防犯グッズカタログ）
リスクアセスメントを行って、「うちのシステムは、どうやらウェブサイトの入り口（ログイン画面）が一番危なっかしいぞ」と分かったとします。
じゃあ、具体的にどうやって守ればいいのでしょうか？
ここで登場するのが、ISO/IEC 27001の「附属書Aの管理策」です。
これは例えるなら、「世界中のセキュリティのプロたちが作った、めちゃくちゃ頼れる『防犯グッズの総合カタログ』」のようなものです。
「パスワードはこう管理しようね」「通信は鍵をかけようね（暗号化）」「万が一のためにバックアップを取っておこうね」といった、先輩たちの知恵と対策が全部で93個もリストアップされています。
「全部を一気にやらなきゃいけないの？」と不安になるかもしれませんが、安心してください。さっきのリスクアセスメントで「うちはここが危ない」と分かった場所に合わせて、このカタログから必要な対策を選んでいけばいいんです。
—
3. 実務への落とし込み：Webアプリを守る具体的な設定
では、この考え方を実際の開発現場に落とし込んでみましょう。
新人の皆さんがよく担当するWebアプリケーションの開発を例に、カタログ（附属書A）から「通信の保護」と「アクセス制御」の管理策をピックアップして、具体的なコードや設定に直してみますね。
例えば、Webサイトの通信を覗き見されないようにする対策（ISO 27001の通信の保護や暗号化に関連する部分）を見てみましょう。現実世界で言えば、郵便物を透明な封筒ではなく、頑丈な鍵付きのトランクに入れて送るようなものです。
ウェブブラウザとサーバーの間の通信を守るためには、HTTPレスポンスヘッダーを正しく設定することが大切です。ここでは、ブラウザに対して「常に安全な暗号化通信（HTTPS）を使ってね」と強制する設定（HSTS）のサンプルを見てみましょう。
Apacheでの設定例 (.htaccess またはバーチャルホスト設定)
実務では、以下のような設定をサーバーに記述して、安全な通信を担保します。
# セキュリティを強化するためのHTTPヘッダー設定
# 1. サイトへのアクセスを強制的にHTTPS（暗号化通信）に切り替える設定 (HSTS)
# ユーザーが「http://」でアクセスしても、強制的に「https://」にリダイレクトさせます。
# これにより、途中で通信内容を盗み見られるリスク（中間者攻撃）を防ぎます。
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
# 2. クリックジャッキング攻撃を防ぐ設定 (X-Frame-Options)
# 悪意あるサイトが、あなたのサイトを透明にして別のボタンの上に重ねる手法を防ぎます。
Header always set X-Frame-Options "SAMEORIGIN"
# 3. 許可されていないスクリプトの実行を防ぐ設定 (X-Content-Type-Options)
# ブラウザがファイルの拡張子を勝手に推測して実行してしまうのを防ぎます。
Header always set X-Content-Type-Options "nosniff"このように、ISOの堅いルールも、「なぜこの設定が必要なのか（リスクは何なのか）」が分かっていれば、ただの「面倒な決まり事」ではなく、「自分たちのシステムを守るための心強い盾」に見えてきませんか？
—
4. 最初の一歩：今日からできること
セキュリティの国際標準やリスクアセスメントというと、どうしても書類仕事や監査のためのものだと思われがちです。でも、本質はもっとシンプルです。
- 自分のシステムの「守るべき宝物」はどこにあるか？
- そこにつながる「ドアや窓」はどこか？
- 「カタログ（附属書A）」から、どの防犯グッズを使えばいいか？
この3つの視点を持つだけで、あなたの書くコードやインフラの構築手順は、ぐっと堅牢で美しいものに変わっていきます。
完璧なセキュリティを初めから目指す必要はありません。まずは身近なリスクに気づき、一歩ずつ適切な対策を重ねていきましょう。
あなたのその丁寧な積み重ねが、組織の大切なデータとユーザーの笑顔を守る最強の盾になります。一緒に一歩ずつ、安全な開発の旅を続けていきましょうね！
コメント