ISO27001附属書Aの技術的管理策（A.8.20〜A.8.24）｜暗号で守るほど、フィルタから中身は見えにくくなる

連載「ISMS審査員・監査への道」の第26回です。前回に続いて、技術的管理策（A.8）を読みます。

経済産業省の情報セキュリティ管理基準は、A.8の管理策を8a〜8dの4つに区切っています。ISOの附属書Aそのものの区切りではなく、管理基準の整理です。今回はその3つ目、「8c 情報システムの適正利用の管理」にあたるA.8.20〜A.8.24の5個を読みます。

5個のうち4個は、ネットワークと暗号の管理策です。どれも2013年版に対応する管理策があり、新規に加わったのはA.8.23のウェブフィルタリングだけです。数も少なく、見慣れた名前が並ぶ区切りだと思って読み始めました。ところが細目に、新規のA.8.23と暗号のA.8.24が引っ張り合う一行がありました。

これまでと同じく、附属書Aの管理策の文と、管理基準が挙げる詳細管理策（以下、細目）は分けて書きます。細目はISO/IEC 27002をもとにした実施の手引です。多くは「考慮する」事項として並んでいます。

---

A.8.20〜A.8.24をひとことで言うと——道を守る、分ける、出口と中身を守る

ひとことで言うと、情報が通る道を守り、道を分け、外への出口と流れる中身を守る5個です。

番号	管理策	ひとことで	2013年版
A.8.20	ネットワークセキュリティ	ネットワークと装置を守り、管理し、制御する	A.13.1.1
A.8.21	ネットワークサービスのセキュリティ	回線などのサービスの要求を決め、監視する	A.13.1.2
A.8.22	ネットワークの分離	グループごとに分け、境界で通すものを決める	A.13.1.3
A.8.23	ウェブフィルタリング	外部のウェブサイトへのアクセスを管理する	新規
A.8.24	暗号の利用	鍵の管理を含め、暗号を使う規則を決める	A.10.1.1、A.10.1.2

対応を見ると、2つのことが分かります。

1つは、2013年版の箇条A.10「暗号」が、丸ごとA.8.24の1個になったことです。A.10には管理策が2つしかなく、その2つが1つにまとまりました。

もう1つは、2013年版の箇条A.13「通信のセキュリティ」が、ばらばらに移ったことです。前半の3つは、今回のA.8.20〜A.8.22へ1対1で移りました。後半の情報の転送の4つは、第17回で読んだA.5.14と、第20回で読んだA.6.6（秘密保持契約）へ移っています。

3つの組に分けて読む

筆者は5個を3つの組に分けて読みました。

組	管理策	何をする組か
道を守る	A.8.20、A.8.21	ネットワークそのものと、その上で受けるネットワークサービス
道を分ける	A.8.22	領域に分け、境界で通すものを決める
出口と中身を守る	A.8.23、A.8.24	外のサイトへの出口を絞る。流れる中身を暗号で守る

この分け方は筆者の整理です。管理基準が5個をこう説明しているわけではありません。

なお、ネットワークの構成は守りの中身そのものです。この回では、筆者の現場のネットワークがどう組まれているかは一切書きません。現場の話は、誰が判断し、誰が手を動かすかという立場の話に限ります。

A.8.20 ネットワークセキュリティ——図と設定を「最新に保つ」が細目にある

A.8.20は、システムやアプリケーションの中の情報を守るために、ネットワークとネットワーク装置のセキュリティを保ち、管理し、制御する管理策です。目的は、ネットワークを通じた侵害から情報を守ることです。

細目は、考慮する事項をa)〜n)の14項目で挙げています。この区切りで一番長い一覧です。

まとまり（筆者の整理）	細目の主な中身
決めておくこと	ネットワークごとに扱ってよい情報の種類と分類レベル。装置の管理の責任と手順。ネットワーク図と構成ファイルを含む最新の文書
役割を分けること	適切な場合には、ネットワークの運用責任を、ICTシステムの運用から分ける
技術的に守ること	公衆・第三者・無線のネットワークを通るデータの保護。システムの認証。接続の制限とフィルタリング。装置の接続の検出。要塞化。管理の経路の分離。ぜい弱なプロトコルの無効化
見張ること・備えること	ログの取得と監視。攻撃を受けたら、重要な部分を一時的に切り離す

最初の項目、ネットワークごとに扱ってよい情報の分類を決める、が目を引きました。第17回で読んだ情報の分類（A.5.12）が、ここでネットワークの側の決まりになっています。どの情報をどの道に流してよいか。それを先に決めてから守り方を選ぶ、という順番です。

最後の一時的な切り離しの例には、ドローブリッジ（跳ね橋）という言葉が使われていました。攻撃を受けたら橋を上げる。正直、比喩として分かりやすいと感じました。

構築の成果物としての図と、細目c)の「最新」

細目c)は、ネットワーク図と、ルーターやスイッチの構成ファイルを含む文書を「最新に」保つよう求めています。

構築を委託する調達では、構成図は構築の成果物として納められる文書だと考えています。第24回の構成管理では、あるべき設定は構築のときの設計書に残ることが多い、と書きました。第9回では、行政の変更管理は完了検査で成果物の完成を見る、とも書いています。どちらも筆者の見方です。

成果物としての図と、細目c)が求める文書を並べると、「正しい」とする時点が違います。

	構築の成果物としての構成図	細目c)が求める文書
作られる時点	構築や大きな更改のとき	変更があるたび
正しさの基準	納品の時点で、構成と一致していること	いま、構成と一致していること
運用中の変更の記録	作業の記録など、別の場所に残ることがある	図と構成ファイルに反映される

納品の時点で正しい図は、大事な土台です。分かれ目は、運用に入ってからの変更をどこに残すかだと考えています。変更のたびに図と構成ファイルを直すのか。作業の記録に残して、必要なときに読み合わせるのか。障害の調査のように急ぐ場面では、読み合わせは骨が折れます。細目c)は、前者を取るよう勧めている書き方でした。

筆者の現場の構成図がどう保たれているかは、構成そのものに近い話なので書きません。

A.8.21 ネットワークサービスのセキュリティ——要求を決め、実装し、監視する

A.8.21は、ネットワークサービスのセキュリティ機能、サービスレベル、サービスの要求事項を特定し、実装し、監視する管理策です。ネットワークサービスとは、回線、インターネット接続、VPNなど、ネットワークを通じて受けるサービスのことです。

細目は、サービスの提供者が組織の内部でも外部でも当てはまる書き方をしています。そのうえで、外部の提供者については次のことが並びます。

• 合意したサービスを安全に管理できる、提供者の能力を決め、定常的に監視する
• 監査の権利について、組織と提供者の間で合意する
• 提供者が対策を保っていることを示すものとして、第三者認証も考慮する

3つ目の項目を読んで、第2回で書いたことを思い出しました。入札の仕様書には認証の要件が入る。けれども、提出された認証書を誰が読んでいるのか、筆者は知らない。調達の手続を所管する課で完結しているのだろう、という話です。

A.8.21の細目は、第三者認証を「考慮する」と書いています。認証があれば足りる、とは書いていません。認証書の適用範囲が、そのサービスを含んでいるか。第2回で書いたその問いが、ネットワークサービスにもそのまま当てはまります。

利用の規則の細目も1つ紹介します。誰がどのネットワークに入ってよいかを決める項目に並んで、「アクセス時の利用者の時刻、場所及びその他の属性」がありました。どこから、いつつないでいるかも、許すかどうかの材料にする。テレワークが広がった後の書き方だと感じました。

A.8.22 ネットワークの分離——分ける基準は、アセスメントから

A.8.22は、情報サービス、利用者、情報システムを、組織のネットワーク上でグループごとに分ける管理策です。目的は、業務のニーズに基づいてネットワークを境界で区切り、その間の通信を管理することです。

細目は、大きなネットワークをいくつかの領域に分け、インターネットからも分けるよう書いています。分け方は、物理的に別のネットワークにしても、論理的に分けてもかまいません。領域の境界ははっきり決め、行き来を許すなら境界にゲートウェイ（ファイアウォールなど）を置いて制御します。

一番大事だと感じたのは、分ける基準の置き場所です。

• 領域をどう分けるか、境界で何を通すかの基準は、各領域のセキュリティ要求事項のアセスメントに基づく
• そのアセスメントでは、アクセス制御の方針や情報の価値・分類に合っているか、ゲートウェイの技術を入れる費用対効果を考えているかを評価する

分けること自体より、なぜその線で分けたかを言えることに重心がある書き方です。費用対効果が評価の項目に入っているのも、現実的だと感じました。全部を細かく分ければ安全ですが、業務が回らなくなります。

無線の細目もあります。無線は電波がどこまで届くかで境界がぼやけるので、特別な扱いが要るとしています。ゲスト用のWi-Fiは要員用から分け、少なくとも要員用と同じ制限をかける、ともありました。

自治体では、分ける考え方が国から示されている

自治体には、この管理策と深く関わる制度があります。国のガイドラインで、ネットワークを複数の系統に分ける考え方（三層の対策）が示されています。LGWAN接続系やインターネット接続系といった系統です。近年は、業務端末をどの系統に置くかで、α・βといった複数のモデルも示されています。

モデルの違いは、自治体のαモデルとβモデルの違いで整理しました。制度の背景はLGWANのルール改定の記事にあります。ここでは筆者の常駐先がどのモデルかには触れず、A.8.22の細目と並べて気づいたことだけを書きます。

	A.8.22の細目	自治体の三層の対策
分ける基準の出どころ	組織が、各領域のセキュリティ要求のアセスメントで決める	国のガイドラインで、分け方の考え方が示されている
組織が選ぶところ	分け方、境界で通すもの、費用対効果	どのモデルを採るか。それに伴う対策と、外部監査などの義務

第9回で、目標は外部から求められたときに立ち上がる、と書きました。分離の基準も、外から来る形です。外から来ること自体は、規格の想定と矛盾しないと考えています。

そのうえで筆者は、モデルを選ぶ検討そのものが、細目の言うアセスメントと費用対効果の評価にあたると読みました。どの系統に何を置くか。そのためにどんな仕組みを入れ、どんな義務を負うか。ここは筆者の整理です。

問われるのは、その検討の跡が残っているかだと考えています。「国がそう示しているから」だけでは、なぜ自分たちはそのモデルを選んだかの説明になりません。検討の記録がどこにあるかは、派遣の立場からは見えていません。

A.8.23 ウェブフィルタリング——道具より先に、規則と例外の手順

A.8.23は、悪意のあるコンテンツにさらされることを減らすために、外部のウェブサイトへのアクセスを管理する管理策です。目的は、マルウェアでシステムが危険にさらされることを防ぎ、認可されていないウェブ資源へのアクセスを防ぐことです。2022年版で新しく入りました。

JNSAのセミナーの解説資料は、不正なウェブサイトへのアクセスを防ぐための新規として紹介していました。技術的な対策の例として、IPアドレスやドメインのブロックが挙がっています。

細目は、塞ぐ先より「規則」に行数を割いている

細目は、塞ぐことを考える先として5つを挙げています。

• 情報をアップロードできるサイト（正当な業務上の理由で許されている場合を除く）
• 悪意のある、またはその疑いのあるサイト
• C&Cサーバ（マルウェアに指令を送るサーバ）
• 脅威インテリジェンスで悪意があると分かったサイト
• 違法なコンテンツを提供しているサイト

1つ目が目を引きました。危ないサイトを塞ぐだけでなく、外へ出す側の出口も塞ぐ対象になっています。情報が外へ持ち出される経路として、アップロードの機能を見ているのだと読みました。

ただ、細目の後半は塞ぐ先の話ではありません。並びはこうでした。

順	細目の中身
1	フィルタリングを入れる前に、オンライン資源を安全かつ適切に使うための規則を作る
2	その規則を最新に保つ
3	要員を訓練する。訓練には、規則、懸念を報告する連絡先、業務上の理由で制限されたサイトに入る必要があるときの例外の手順を含める
4	ブラウザが出す「安全でない」という警告を、利用者が無効にしないよう訓練する

「入れる前に」と順番まで書いてあるのは、正直意外でした。道具を入れてから規則を後追いで作る、という順番を戒めているように読めます。

教科書は、フィルタの方式としてブラックリスト、ホワイトリスト、カテゴリの3つを説明しています。一方、管理基準の細目は方式を指定していません。望ましいサイトと望ましくないサイトの「種類を特定する」と書いているだけです。どの方式を採るかは、組織が決めることになります。

現場から：例外は、原課が申し出て、職員が判断し、筆者が設定する

第15回で、ウェブフィルタリングは規格に入る前から筆者の現場で仕事になっていた、と書きました。今回はその中身を1つ聞きました。

業務で必要なサイトがフィルタで止まったとき、見られるようにするまでの流れです。業務を所管する課（原課）が申し出て、職員が判断し、筆者が設定を変えます。

細目の3番目にある「例外の手順」が、現場で回っている形です。

例外の流れ	担う人	細目との対応（筆者の整理）
業務上の理由で、見る必要があると申し出る	原課	正当な業務上の理由
通してよいかを判断する	職員	例外の手順の判断
フィルタの設定を変える	筆者	手順に沿った実施

判断する人と、手を動かす人が分かれています。第6回で書いた、責任は筆者に、権限は職員に、という形と同じです。第19回のソフトウェアの導入でも、同じ分担を書きました。

筆者の位置から見ると、この形には強みがあります。設定を変える人が、自分の判断で例外を足すことはありません。通した例外には、必ず判断した人がいます。

細目と並べて残った問いは2つです。1つは、職員が判断するときの物差しです。細目1番目の「規則」がそれにあたるはずですが、筆者は判断の材料までは見ていません。もう1つは、一度通した例外のその後です。業務が変わって要らなくなった例外を、見直す機会があるか。細目2番目の「最新に保つ」は、ここに効いてくると考えています。どちらも今回は確かめていません。

A.8.24 暗号の利用——鍵の一生を管理する

A.8.24は、暗号鍵の管理を含む、暗号を効果的に使うための規則を定め、実施する管理策です。目的には、情報の機密性、真正性、完全性を守るため、と並び、暗号に関わる法令や契約上の要求事項を考えることも入っています。

細目は、暗号の利用全般と、鍵管理の2つに分かれています。

暗号の強さは、情報の分類から決める

暗号の利用全般の細目で、まず目を引いたのは強さの決め方です。求められる保護のレベルと情報の分類を特定し、その結果から、暗号のアルゴリズムの種類、強度、品質を決める、とありました。

A.8.20の細目と同じく、ここでも情報の分類が出発点になっています。何を守るかが決まって初めて、どれだけ強く守るかが決まる。第17回の分類が、ネットワークにも暗号にも効いていることになります。

暗号で守るほど、検査から中身は見えにくくなる

全般の細目の最後に、この回で一番引っかかった一行がありました。暗号化した情報を使うことが、コンテンツの検査に頼る管理策にどう影響するかを考える、というものです。検査の例には、マルウェアの検出とコンテンツのフィルタリングが挙がっています。

	暗号（A.8.24）	中身を検査する管理策（A.8.23など）
ねらい	中身を第三者に読ませない	中身を見て、危ないものを止める
強めると	途中の経路から中身が見えにくくなる	中身を見るための仕組みが要る
細目の書き方	暗号化が検査に頼る管理策に与える影響を考える（A.8.24の細目）

暗号で中身を守るほど、途中で中身を確かめる仕組みからは見えにくくなります。暗号化の仕方によっては、検査に頼る管理策のやり方に影響が出る、という関係です。新規のA.8.23と、2013年版のA.10を吸収したA.8.24が、同じ区切りの中で引っ張り合っているように、筆者には見えました。

ただし、これは「暗号化すればフィルタリングができなくなる」という意味ではありません。暗号化した通信を検査する技術もあります。暗号化とコンテンツの検査をどう両立させるか、その影響を考えておくことが細目の趣旨だと読みました。

細目は、どちらを優先せよとは書いていません。影響を考える、と書いているだけです。暗号の規則を決めるときに、検査の側の管理策を一緒に見る。管理策を1つずつ読むと見落としやすい組み合わせを、細目が拾っていると感じました。なお、これは管理策の文ではなく、細目の話です。

鍵管理は、生まれてから壊されるまで

鍵管理の細目は、a)〜m)の13項目です。並べると、鍵の一生をたどる形になっていました。

段階	細目の主な中身
生まれる	鍵を生成する。公開鍵証明書を発行し、入手する
渡る・使われる	意図した相手に配る。保管し、認可された人だけが使えるようにする
入れ替わる	いつ、どう変更・更新するかの規則。危殆化（安全でなくなること）した鍵に対処する
使えなくなる	無効にする（利用者が組織を離れたときも含む）。活性化と非活性化の日付を決める
失われる・壊される	紛失・破損した鍵を回復する。バックアップする。破壊する
通して	鍵管理の活動を記録し、監査する

「活性化と非活性化の日付を決める」という項目は、組織の規則に従って、鍵を一定の期間だけ使えるようにするためのものです。鍵管理の一部で、期限だけを管理すれば済むという話ではありません。身近なところでは、サーバ証明書にも有効期限があります。期限が切れると、利用者のブラウザに警告が出ます。A.8.23の細目が「無効にしないよう訓練する」と書いていた、あの警告です。

現場から：証明書の期限は、委託先が知らせてくる

筆者の現場では、サーバ証明書などの期限が近づくと、委託先から知らせが来ます。それを受けて更新が進む形です。

これは、第16回の脅威情報や、前回のアラートと同じ分担です。どちらも、専門の判断は委託先から届いていました。証明書の期限は、うっかりすると業務が止まる種類の日付です。それを日々の仕事として追う専門の人が見ているのは、筋の通った形だと考えています。

細目と並べると、組織の側に残る部分が見えてきます。

鍵管理の細目	どちらの側の仕事か（筆者の整理）
期限を追い、更新の時期を知らせる	委託先（筆者の現場）
鍵管理の役割と責任を決める	組織。細目は役割と責任を考慮事項に挙げている
どんな鍵・証明書がいくつあるかを把握する	組織が持つか、委託先ごとに分かれるか

気になったのは3行目です。委託先が複数あれば、知らせもそれぞれから届きます。1社の知らせが漏れたとき、それに気づけるのは、全体の一覧を持っている人だけです。証明書の一覧を組織の側でまとめて持っているかどうかは、今回確かめていません。

よくある落とし穴／審査で指摘されやすい点

ネットワーク図が、構築したときのまま

細目は、ネットワーク図と構成ファイルを含む文書を最新に保つよう求めています。変更の記録が別の場所にあっても、いまの姿を示す1枚を出せるかは聞かれやすい点だと考えています。

フィルタは入っているが、規則と例外の手順を示せない

A.8.23の細目は、フィルタリングを入れる前に規則を作り、例外の手順を訓練に含めるよう書いています。道具の設定画面だけでは、何を基準に塞ぎ、何を基準に通したかの説明としては弱くなりがちです。通した例外を見直しているかも、問われることがあると考えています。

分離の基準を「国がそう示しているから」だけで説明する

A.8.22の細目は、分ける基準をアセスメントに置いています。外から示された枠組みに沿っていても、自分たちがその分け方を選んだ理由と、費用対効果の検討を説明できると強いと考えています。

暗号化はしているが、鍵と証明書の持ち主と期限を言えない

鍵管理の細目は、鍵の生成から破壊まで、役割と責任を決めるよう求めています。委託先が期限を追っている場合も、組織として何がいくつあるかを把握しているかは聞かれやすい点です。

暗号の規則と、検査の管理策を別々に決めている

暗号の細目は、暗号化が検査に頼る管理策に与える影響を考えるよう書いています。2つを別々の担当が別々に決めていると、つなぎ目が抜けやすいと考えています。

まとめ

• A.8.20〜A.8.24の5個は、管理基準の「情報システムの適正利用の管理」です。2013年版のA.10「暗号」は丸ごとA.8.24に、A.13の前半3つはA.8.20〜A.8.22にそのまま移りました。新規はA.8.23だけです
• A.8.20の細目は、ネットワーク図と構成ファイルを最新に保つよう求めています。構築の成果物としての図は納品の時点で正しく、運用に入ってからの変更をどこに残すかが分かれ目になると考えています
• A.8.21は、内部・外部を問わず、ネットワークサービスのセキュリティ機能やサービスレベルを特定し、実装し、監視する管理策です。外部の提供者については、第三者認証は「考慮する」で、認証があれば足りるとは書いていません
• A.8.22の細目は、分ける基準をアセスメントに置いています。自治体では分け方の考え方が国から示されており、モデルを選ぶ検討がそのアセスメントにあたる、と筆者は読みました
• 新規のA.8.23は、道具より先に規則と例外の手順を求めています。筆者の現場では、例外は原課が申し出て、職員が判断し、筆者が設定します
• A.8.24の細目は、暗号化がフィルタリングなどの検査に与える影響まで考えるよう書いています。証明書の期限は委託先が知らせてきますが、組織として一覧を持っているかは確かめていません

次回は、管理基準の4つ目の区切り（8d）にあたるA.8.25〜A.8.34を読みます。セキュリティに配慮した開発のライフサイクル、外部委託による開発、変更管理などが並び、技術的管理策はそこで読み終わります。

連載の入口は第1回です。

参考にした一次資料

• 経済産業省「情報セキュリティ管理基準（令和7年改正版）」 … 管理策基準の8c（8.20〜8.24）の管理策・目的・詳細管理策を読みました。JIS Q 27001:2023、JIS Q 27002:2024をもとにした版です。本文は意見公募時に公開されていた版から読んでいます
• 情報セキュリティマネジメント・セミナー2022 講演資料（JNSA 日本ISMSユーザグループ／2022年12月16日） … 「ISO/IEC 27002 改定の解説」（土屋直子／NTTテクノクロス）で、8.23が新規であることと、その趣旨を確認しました
• 地方公共団体における情報セキュリティポリシーに関するガイドライン（総務省） … 三層の対策とモデルの存在に触れるために挙げています。中身は内部リンク先の記事で扱っています。改定が続いているため、一覧ページから最新版を開いてください
• 岡田敏靖『ISO27001:2022の規格と審査がしっかりわかる教科書 改訂2版』（技術評論社） … 連載で使っている教科書です。35節（A.8）のうちA.8.20〜A.8.24の説明を読みました。2013年版の番号は、付録の対応表（27002:2022の附属書Bをもとに作成、と注記あり）から引いています

引っかかった点

教科書のA.8.24の見出しは「暗号の使用」でした。管理基準の管理策名は「暗号の利用」です。記事では管理基準の語で書きました。

教科書のA.8.20の説明では、ネットワークとコンピュータの運用責任を分けることを、内部不正を防ぐ牽制の仕組みとして説明していました。管理基準の細目は「適切な場合には」と条件を付けたうえで、ネットワークの運用責任をICTシステムの運用から分ける、と書いています。目的は書かれておらず、参照先は役割の分離（A.5.3）でした。内部不正の防止は、その分離から読み取れる効果の1つだと考え、記事では細目の語だけで書きました。

教科書のA.8.20の説明は、考慮する事項を7つ挙げていました。管理基準の細目は14項目と、仮想化ネットワークの項目です。教科書の7つが2013年版の項目立てを引き継いでいるかどうかは、2013年版の本文を手元で照らせていないため、判断していません。

2013年版のA.13.1.1、A.10.1.1、A.10.1.2の管理策名は、手元の資料で確かめられていません。記事では番号だけを書きました。