ISO27001附属書Aの技術的管理策（A.8.7〜A.8.12）｜新規4つが並ぶ、持っているものを知る6つ

連載「ISMS審査員・監査への道」の第24回です。前回から、技術的管理策（A.8）を読んでいます。

経済産業省の情報セキュリティ管理基準は、A.8を4つに区切っています。今回は2つ目の区切り「情報資産運用に関する管理」です。ただ、ここには13個の管理策があり、1回で読むには多すぎました。そこで前半のA.8.7〜A.8.12の6個を今回、後半のA.8.13〜A.8.19の7個を次回に分けます。

前半の6個には、2022年版で新しく入った管理策が4つ並んでいます。新規の11個は、A.5.7、A.5.23、A.5.30、A.7.4、A.8.9〜A.8.12、A.8.16、A.8.23、A.8.28です。番号が続けて並ぶのは、このA.8.9〜A.8.12の4つだけでした。

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

---

A.8.7〜A.8.12をひとことで言うと——持っているものを知り、守り、消し、隠す

ひとことで言うと、組織が持っている情報とシステムを、運用の中で守り続ける6個です。筆者は2個ずつに分けて読みました。最初の2個が外からの攻撃への備え、次の2個が持ち方の管理、最後の2個が情報を外に出さないための管理です。

番号	管理策	ひとことで	2013年版
A.8.7	マルウェアに対する保護	マルウェアから守り、利用者の認識で支える	A.12.2.1
A.8.8	技術的ぜい弱性の管理	脆弱性の情報を得て、評価し、手を打つ	A.12.6.1、A.18.2.3
A.8.9	構成管理	あるべき設定を決め、記録し、ずれを見張る	新規
A.8.10	情報の削除	要らなくなった情報を消す	新規
A.8.11	データマスキング	見せる必要のない部分を隠す	新規
A.8.12	データ漏えい防止	漏えいを検知し、防ぐ	新規

2013年版の3つの管理策が、2022年版ではA.8.7とA.8.8の2つに整理されました。A.8.8に2個がまとまっています。

まとまったうちのA.18.2.3は、技術的順守のレビューです。第19回で、統合先がA.5.36とA.8.8の2つある、と書いたものでした。そのとき「技術的な点検の中身はA.8.8の回で扱う」と予告しています。今回、その続きを読みます。

6個に共通する前提——持っているものが分かっていること

6個の細目を並べて読むと、どれも同じ前提に立っていることに気づきました。守る、消す、隠す。その前に、何を持っているかが分かっていないと始まらない書き方です。

管理策	前提として要るもの	細目の書き方
A.8.7	どのソフトウェアが認可されているか	認可されていないソフトウェアの使用を防ぎ、検出する（許可リストの例）
A.8.8	どのソフトウェアの、どの版が、どこにあるか	効果的な脆弱性管理の前提条件として、正確な資産の目録をもつ
A.8.9	あるべき設定	セキュリティを保った構成の標準テンプレートを決める
A.8.10	消すべき情報が、どこにあるか	古い版、複製、一時ファイルは、どこにあっても削除する
A.8.11	どれが慎重に扱うデータか	例えば個人を識別できる情報（PII）を、マスキングで隠すことを検討する
A.8.12	漏えいから守る情報はどれか	守る情報を特定し、分類する

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

ただ、前提の多くは、第17回で読んだ組織的管理策の側にあります。資産の目録（A.5.9）と、情報の分類（A.5.12）です。第17回では「数えて、分けて、渡す」と書きました。その「数えて、分けて」が、今回の6個では技術の側の出発点になっています。

A.8.7 マルウェアに対する保護——ソフトだけでは足りない、と細目が書く

A.8.7は、マルウェアに対する保護を実施し、利用者の適切な認識によって支援する管理策です。

マルウェアとは、ウイルスやランサムウェアなど、悪意をもって作られたソフトウェアの総称です。管理策の文に、対策ソフトという言葉は出てきません。代わりに入っているのが「利用者の認識」でした。

細目は、対策ソフトを単独で使うことは十分でない、と書く

細目は、保護の土台を3つ挙げています。検出・修復のソフトウェア、情報セキュリティの認識、そしてシステムへの適切なアクセスと変更の管理です。そのうえで、検出・修復ソフトウェアを単独で使うことは通常十分ではない、と添えていました。

続く手引は15項目あります。認可されていないソフトウェアの防止、悪意のあるサイトの遮断、スキャン、多層防御、回復のためのバックアップ、利用者への意識向上などです。他の管理策を参照する項目が多く、A.8.7は守りの寄せ集めの入口のように読めました。

目を引いたのは、守りが緩む時間の2項目

その中で目を引いたのは、守りが一時的に緩む場面を扱う2項目でした。

1つは、保守や緊急時の手順の途中で、マルウェアが入り込むことに注意を払う、という細目です。保守の作業では、通常の管理策を迂回することがあるからです。筆者は保守で機器に触る側なので、ここは身につまされました。

もう1つは、マルウェア対策を一時的に、または恒久的に止めることを認可するプロセスです。例外を承認する権限、文書化した正当性、見直しの日付を含める、とありました。対策ソフトが業務を止めてしまい、外さざるを得ない場面は現実にあります。外すこと自体を禁じず、外し方を管理させる書き方だと受け取りました。

A.8.7も、端末の守りを具体的に書くほど、組織の守りの中身の説明になります。前回のA.8.1と同じ理由で、ここは細目の紹介にとどめます。

A.8.8 技術的ぜい弱性の管理——当てるリスクと、当てないリスクを比べる

A.8.8は、利用中の情報システムの技術的ぜい弱性について情報を獲得し、さらされている状況を評価し、適切な手段をとる管理策です。

技術的ぜい弱性とは、ソフトウェアや機器の弱点のことです。攻撃者はこの弱点を突いてきます。修正のための更新は、パッチと呼ばれます。

細目は、特定・評価・対処の3段で並ぶ

管理基準の細目には見出しが付いていて、特定、評価、対処の3段に分かれています。

段	細目の主な中身
特定	正確な資産の目録をもつ。役割と責任を決める。情報源を決めて更新する。供給者に、契約で脆弱性の報告と開示を求める。スキャンツールや侵入テストで見つける
評価	報告を分析して検証し、どんな対応が要るかを決める。リスクと、講じる処置を特定する
対処	通知に対応するまでの期限を決める。緊急性に応じて、変更管理か、インシデント対応の手順で動く。適用の前に試す。リスクの高いシステムから手を付ける

特定の段の最初にあるのが、正確な資産の目録です。目録には、ソフトウェアの業者、名前、版、どのシステムに入っているか、担当者を含める、とありました。冒頭の表で「前提」と書いたのは、この細目です。

A.18.2.3の行き先は、スキャンと侵入テストだと読んだ

第19回の宿題だった、技術的順守のレビュー（A.18.2.3）の行き先です。

A.8.8の細目には、使っている技術に合ったスキャンツールで、脆弱性とパッチの適用の成否を確かめる、という項目があります。力量があり認可された人が、計画して文書化した侵入テストや脆弱性アセスメントを行う、という項目もありました。技術的な点検は、この2つの細目に着地した、と筆者は読んでいます。管理基準も教科書も、そこまでは明示していません。

更新にもリスクがある、と細目が言う

一番うなずいたのは、対処の段の注記です。更新を適用する前に、脆弱性が引き起こすリスクと、更新を適用することのリスクを比べる、と書かれていました。

更新を当てれば、業務のシステムが動かなくなることがあります。当てなければ、弱点を突かれるかもしれません。どちらにもリスクがあり、比べたうえで選べ、という書き方です。

更新を当てられない場合の手も、細目に6つ並んでいます。業者が示す回避策、関係する機能の停止、境界でのアクセス制御の調整、通信を絞るフィルタ（仮想パッチ）、監視の強化、認識の向上です。

自動更新の機能があるソフトウェアについては、自動更新を使うかどうかを組織が決める、ともありました。使えとも、使うなとも書いていません。細目が組織に求めているのは、決めることでした。

現場から：知らせが来ても、すぐには当てず待つ

筆者の現場では、修正の知らせが来ても、すぐには当てずに待つのが基本です。

前述の通り、自分たちに関係があるかの見立ては、保守の委託先から届きます（第16回）。版上げの知らせは職員に届き、筆者に回ってきます（第18回）。待つのは、この流れの中で確かめる時間が要るからだと筆者は見ています。

細目には、適用の前に更新を試して評価する、という項目があります。そのため、試験や評価のために適用を待つ判断自体は、あり得るものです。業務を止められないシステムほど、当てるリスクは重くなります。ただし、待つことがそのままA.8.8に沿うわけではありません。対応の期限や、待っている間のリスクの扱いまで含めて管理することになります。

そのうえで、細目と並べると、待つことにも決めておく点があると気づきました。

細目	待つときに当てはまる問い
通知に対応するまでの期限を決める	どれだけ待つかは、決まった長さか、その都度か
リスクの高いシステムから対処する	待つ長さに、システムの重さで差を付けているか
更新を当てられない場合は、代わりの手を検討する	待っている間を、どう扱うか

3行目の代わりの手は、本来は「更新が無い、または当てられない」場合の細目です。ただ、待っている間も、当てていない状態であることに変わりはありません。待つと決めたなら、待つ長さと、その間の扱いまで含めて決めた形にしておく。細目の並びは、その材料になると考えています。ここは、細目を「待つ」という判断に当てはめた筆者の整理です。

外から見て区別できるのは、待つと判断した跡が残っているかどうかです。第8回で書いた、受容と放置は記録の有無でしか区別できない、という話と同じ形の問いでした。

A.8.9 構成管理——台帳の先に「あるべき設定」を持つ

A.8.9は、ハードウェア、ソフトウェア、サービス、ネットワークについて、セキュリティ構成を含む構成を確立し、文書化し、実装し、監視し、レビューする管理策です。2022年版で新しく入りました。

目的は、必要なセキュリティ設定で正しく動いていること、そして認可されていない変更や誤った変更で構成が変えられないことです。

教科書は台帳寄り、細目は設定寄り

読み比べて、少し戸惑いました。教科書は構成管理を、システムが動く環境の情報を最新の状態で管理すること、と説明しています。対象には、機器やソフトに加えて、契約情報やベンダー情報まで挙がっていました。台帳の作り方に近い説明です。

管理基準の細目は、重心が違います。中心にあるのは、セキュリティを保った構成の「標準テンプレート」でした。

	台帳寄りの読み方	細目の重心
持つもの	機器・ソフト・契約などの一覧	あるべき設定（標準テンプレート）と、決めた構成の記録
見張るもの	一覧が最新か	実際の設定が、テンプレートからずれていないか
ずれたとき	一覧を直す	テンプレートを当て直すか、ずれを分析して是正する

どちらが誤りという話ではないと考えています。一覧の側は、資産の目録（A.5.9）で求められているものと重なります。A.8.9の細目は、その一覧の先にある「どう設定されているべきか」まで書いている、と筆者は読みました。

テンプレートには、他の管理策が集まってくる

標準テンプレートは、業者や独立したセキュリティ組織が公開している手引を使い、必要な保護の水準と、組織の方針に合わせて決めます。定期的に見直すことに加え、新しい脅威や脆弱性、新しい版の導入があれば更新する、とありました。

テンプレートを作るときに考える事項は8つです。並べてみると、他の管理策で読んだものが集まっていました。

テンプレートで考える事項	関係する管理策
特権をもつIDの数を最小限にする	A.8.2 特権的アクセス権
不要なID、使っていないIDを無効にする	A.5.18 アクセス権
不要な機能とサービスを止める	—
強力なユーティリティと、設定値へのアクセスを制限する	A.8.18 特権的なユーティリティプログラムの使用
時刻を同期させる	A.8.17 クロックの同期
業者の初期パスワードを、導入の直後に変える	A.5.17 認証情報
一定時間使わなければ、自動でログオフする	—
使用許諾の条件を満たしているか確かめる	A.5.32 知的財産権

右の列は、筆者が対応付けたものです。管理基準が参照を張っているのは、最後の使用許諾（A.5.32）だけでした。

それでも、並べると見えてくるものがあります。他の管理策で決めたことは、最後には機器の設定値として現れます。A.8.9は、その設定値を1か所で持ち、ずれを見張る管理策だと考えています。

記録と、ずれの確かめ方

決めた構成は記録し、全ての構成変更のログを残します。構成の変更は、変更管理（A.8.32）に従います。

構成の記録に含められるものとして、資産の管理責任者か連絡先、最終変更日、テンプレートの版、他の資産との関係が挙がっていました。書き方は「含み得る」です。必ず入れる項目として並んでいるわけではありません。

最後の細目が、A.8.9の要だと感じました。実際の構成を、目標のテンプレートと比べる。ずれていれば、テンプレートを自動で当て直すか、手で分析して是正処置をとる、というものです。

現場から：構成管理は、資産管理ツールの台帳

第15回で、構成管理は規格に入る前から仕事になっていた、と書きました。中身を振り返ると、資産管理ツールの台帳です。機器とソフトウェアの一覧が、ツールの側にそろっています。

先ほどの表に当てると、台帳寄りの側でした。

これは、A.8.8の前提としては強いと考えています。細目が目録に求めるのは、ソフトウェアの名前、版、どこに入っているか、でした。台帳で当たれる項目が多いので、脆弱性の知らせが来たとき、関係があるかを調べる最初の手がかりになります。

一方で、A.8.9の細目の重心である「あるべき設定」は、台帳とは別の層です。台帳は、いま何があるかを示します。どう設定されているべきかまでは示しません。

では、あるべき設定はどこで決まるのか。第16回で、ログや権限などの細部は構築の途中で決まっていく、と書きました。委託で作るシステムでは、決まった設定値は構築のときの設計書に残ることが多いと思います。ここは筆者の見方です。

細目が求めているのは、その設定をテンプレートとして持ち続け、運用中の実際の設定と比べることでした。構築の設計書が、完成とともに役目を終えるのか。比べる物差しとして運用に引き継がれるのか。ここは今回、確かめていません。

前述の通り、やっていることと、管理策を満たしていることは別です。台帳があることは、A.8.9を説明するときの出発点になると考えています。

A.8.10 情報の削除——要らなくなったら消す、を管理策にした

A.8.10は、情報システム、装置、その他の記憶媒体に保存している情報を、必要でなくなった時点で削除する管理策です。これも2022年版の新規です。

目的は2つあります。慎重に扱う情報が、不用意に漏れるのを防ぐこと。そして、情報の削除に関する法令、規制、契約上の要求を守ることです。

機器を手放すときの話だけではない

削除と聞くと、第22回で読んだA.7.14を思い出します。装置を処分する前に、データが消えたことを検証する管理策でした。

JNSAのセミナーの解説資料も、A.8.10の目的を、機器や装置の廃棄の段階での情報漏えいの防止、と説明していました。ただ、管理基準の細目を読むと、対象はそれより広く並んでいます。

	A.7.14 装置の処分・再利用	A.8.10 情報の削除
対象	記憶媒体を内蔵した装置	システム、装置、記憶媒体に保存している情報
いつ	処分や再利用の前	必要でなくなった時点（運用中も含む）
細目が挙げる場所	装置の中の記憶媒体	古い版、複製、一時ファイル（どこにあっても）、クラウド、第三者に預けた情報

装置を物理的に壊すときは、A.7.14の対策を当てる、という細目もあります。2つは別々の管理策ですが、手放す場面でつながっています。

細目は、消し方と、消した証拠の残し方を挙げる

細目は、消し方と証拠の両方を、考慮する事項として挙げています。消し方は、業務の要求と法令を踏まえて選びます。例は、電子的な上書きや暗号化消去でした。証拠は、削除の結果を記録し、削除の業者を使うなら、その業者から得ます。記録は、後で漏えいが疑われたときの原因分析にも役立つ、と添えられていました。第22回で書いた、業者の証明書で職員が確かめる形は、この細目に当たると考えています。

組織の外にある情報にも、目が向いています。第三者が組織に代わって情報を保存しているなら、削除の要求を合意に含め、サービスの実施中と終了時に実行させることを検討する、とありました。

消すことと、残すことは、同じ方針の裏表

注意したいのは、A.8.10が「とにかく消せ」とは書いていないことです。削除は、データ保持に関する組織の方針に従い、法令を考慮して行う、とあります。

自治体の文書には、法令や規程で決まった保存期間があります。第11回では、紙の文書は公文書の保存年限の仕組みに乗る、と書きました。消してはいけないものを消すのも、問題になります。

管理策の文と細目を合わせて読むと、「いつまで要るか」を方針で決め、要らなくなったら確実に消す、という形になります。残す理由と消す時点は、同じ方針の裏表だと考えています。

現場から：消すきっかけは、容量

要らなくなった電子データを消すきっかけは、筆者の現場では容量です。置き場所が足りなくなってきたら、整理します。

ここで、前回読んだA.8.6を思い出しました。容量・能力の管理の細目は、需要を減らす手として、古いデータの削除を挙げていました。筆者の現場の削除は、A.8.10よりも、A.8.6の理屈で動いていることになります。

	A.8.6の理屈で消す	A.8.10の理屈で消す
目的	置き場所を空ける	不用意な漏えいを防ぎ、法令などを守る
消す時点	置き場所が足りなくなったとき	必要でなくなったとき
消すものを選ぶ物差し	古さと大きさ	まだ要るかどうか

容量で消すのは、筋の通ったやり方です。消す作業が実際に回り、置き場所も守られています。第11回で書いた、ログの保存期間が設定と容量で決まっている話とも同じ形でした。

違いが出るのは、場所を取らない古いデータです。容量で消す形では、置き場所に余裕があるうちは、要らなくなったものも残り得ます。逆に、第13回で書いた問い合わせ履歴のように、要るから残しているものもあります。外から見ると、要るから残っているのか、場所が足りているから残っているのかは区別できません。

分かれ目は、第11回の保存期間と同じく、「それで足りる」と判断した跡だと考えています。慎重に扱う情報を含むものだけでも、いつまで要るかを決めておく。細目の言葉で言えば、データ保持の方針に乗せる、ということです。

A.8.11・A.8.12 隠すことと、漏らさないこと

残りの2個も、2022年版の新規です。どちらも、慎重に扱う情報が外に出ることを防ぐ管理策ですが、手の打ち方が違います。A.8.11は情報そのものを見えにくくし、A.8.12は情報が出ていく経路を見張ります。

A.8.11 データマスキング——隠し方は、仮名化と匿名化だけではない

A.8.11は、データマスキングを、適用される法令を考慮し、アクセス制御などの方針と事業上の要求に従って使う管理策です。データマスキングとは、データの一部を隠したり置き換えたりして、見せる必要のない部分を見えなくする手法のことです。

細目は、まず仮名化と匿名化を挙げています。仮名化は、氏名などの識別子を別の符号に置き換え、直接には本人を識別しにくくする方法です。追加の情報と組み合わせると、本人と結び付けられる場合があります。匿名化は、他の情報と組み合わせても個人を識別できないように加工することを目指す方法です。

それ以外にも、暗号化、文字の消去、数や日付の変更、値の置換、ハッシュ値への置換が並んでいました。

一番大事だと感じたのは、匿名化の検証です。直接に誰か分かるデータを隠しても、別のデータと組み合わせると誰か分かってしまう場合がある、と細目は注意しています。生年月日と住所の一部と性別だけで、人が絞り込めてしまうような場合です。隠したことと、分からなくなったことは別だ、ということだと読みました。

ここで、このブログ自体のことを思いました。筆者は現場の話を書くとき、名前や構成を伏せたり、ダミーに置き換えたりしています。細目の言葉で言えば、置換や消去にあたります。組み合わせると分かってしまわないかを気にするのも、匿名化の検証と同じ悩みでした。

法令との関係は、少し注意が要ります。教科書は、個人情報保護法の「仮名加工情報」「匿名加工情報」を使って説明していました。法令の加工の定めと、規格のデータマスキングは、同じ範囲を指しているわけではありません。管理策の文も、法令は「考慮する」ものとして書いています。

A.8.12 データ漏えい防止——製品の名前ではなく、対策の名前

A.8.12は、データ漏えい防止の対策を、慎重に扱う情報を処理、保存、送信するシステム、ネットワーク、その他の装置に適用する管理策です。

データ漏えい防止は、英語の頭文字でDLPとも呼ばれます。DLPという名前の製品もあるため、製品を入れる管理策だと思われがちです。ただ管理策の文は「対策を適用する」でした。

細目は、守る情報の特定と分類、漏えいの経路の監視、漏えいを防ぐ処置の3つから始まります。経路の例は、電子メール、ファイル転送、持ち運べる記憶媒体などです。そのうえで、組織の外のサービスや機器へのコピーやアップロードを制限する必要があるかを判断する、とありました。制限するなら、DLPツールか、既存のツールの組み合わせで実装します。製品の導入は、手段の1つという書き方です。

もう1つ目を引いたのは、データの取り出しを許す役割を、データの管理責任者に与える、という細目です。取り出しが要る場面を認めたうえで、許した人に説明の責任を持たせています。画面のスクリーンショットや写真は、利用条件、訓練、監査で扱う、ともありました。技術だけで防ぎきれないものは、人の側で扱う書き方です。

自治体には、経路を分けるという強い手がある

自治体の情報セキュリティ対策には、ネットワークを用途ごとに分ける、という仕組みがあります。いわゆる三層の対策です。漏えいの経路そのものを分けてしまう、強い手だと思います。

ただ、附属書Aで経路を分ける話は、主にネットワークの分離（A.8.22）の側で読むものだと考えています。A.8.12は、分けた経路の上で、何が出ていこうとしているかを見張る側です。A.8.22は、技術的管理策の3つ目の区切りで読む予定です。

A.8.12の細目には、信頼できない第三者のクラウドサービスに情報がアップロードされたら検出する、という例もありました。第3回で、業務を所管する課でもAIの利用が始まっていると書きました。生成AIに業務の文章を貼り付ける場面は、この例の延長にあると感じます。

第3回では、共通の言葉がないと、議論が「使う」「使わせない」の二択に落ちる、とも書きました。A.8.12の細目が求めているのは、制限する必要があるかの「判断」です。禁止を決めろとは書いていません。どの情報を、どの経路で、どこまで許すか。分類と経路の両方を持って初めて、二択の手前で話ができると考えています。

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

対策ソフトを入れたことだけで、A.8.7を説明する

細目自身が、検出・修復ソフトウェアを単独で使うことは通常十分でない、と書いています。利用者の認識と、ソフトウェアの導入の管理まで含めて説明できるかが問われやすいと考えています。

更新を待つと決めたのに、待つ長さと待つ間の扱いを言えない

細目には適用前の試験と評価があるので、そのために待つ判断自体はあり得ます。問われやすいのは、どれだけ待つのか、待っている間をどう扱うのかを説明できるかだと考えています。

構成管理を、台帳の有無だけで説明する

資産の台帳は、目録（A.5.9）としても、A.8.8の前提としても強い材料です。ただ、A.8.9の細目の重心は、あるべき設定を持ち、実際の設定と比べることにあります。比べる物差しをどこで持っているかまで聞かれることがあると考えています。

削除を、機器を手放すときと、容量が足りないときだけの話にする

機器の処分は、証明書まで含めて強い形になりやすいと思います。一方、運用中の古い版や複製は、消す理由が容量に寄りがちです。A.8.10は「必要でなくなった時点」で消す管理策です。慎重に扱う情報だけでも、いつまで要るかを決めた跡があると、説明しやすくなります。

データ漏えい防止を、製品の有無で答える

管理策の文は「対策を適用する」です。守る情報の特定と分類、経路の監視、制限が要るかの判断が先にあります。製品があっても、守る情報が決まっていなければ、何を見張っているかを説明しにくくなります。

まとめ

• A.8.7〜A.8.12の6個は、管理基準の「情報資産運用に関する管理」の前半です。2013年版の3つの管理策がA.8.7とA.8.8の2つに整理され、そこに2022年版の新規4個が加わりました
• 6個とも、何を持っているかが分かっていることを前提に書かれています（筆者の整理）。前提の多くは、資産の目録（A.5.9）と情報の分類（A.5.12）の側にあります
• A.8.8の細目は、更新を当てるリスクと当てないリスクを比べること、当てられないときの代わりの手を挙げています。筆者の現場では、知らせが来てもすぐには当てず待つのが基本です。待つ長さと、待つ間の扱いまで決めた形にしておくことが問われると考えています
• A.8.9の細目の重心は、台帳よりも、あるべき設定（標準テンプレート）と実際の設定の比較にあります。筆者の現場の構成管理は資産管理ツールの台帳で、A.8.8の前提には強い一方、あるべき設定との比較は別の層です
• A.8.10は、機器を手放すときに限らず、要らなくなった情報を消す管理策です。消す時点は、残す理由と同じ方針で決まります。筆者の現場で消すきっかけは容量で、A.8.6の理屈で動いています
• A.8.11は手法の名前、A.8.12は対策の名前で、どちらも製品の名前ではありません。隠したことと分からなくなったこと、製品があることと守る情報が決まっていることは、それぞれ別です

次回は、情報資産運用に関する管理の後半、A.8.13〜A.8.19（バックアップ、冗長性、ログ取得、監視活動など）を読みます。

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

参考にした一次資料

• 経済産業省「情報セキュリティ管理基準（令和7年改正版）」 … 管理策基準の8b（8.7〜8.12）の管理策・目的・詳細管理策を読みました。JIS Q 27001:2023、JIS Q 27002:2024をもとにした版です。本文は意見公募時に公開されていた版から読んでいます
• 情報セキュリティマネジメント・セミナー2022 講演資料（JNSA 日本ISMSユーザグループ／2022年12月16日） … 「ISO/IEC 27002 改定の解説」（土屋直子／NTTテクノクロス）で、8.9〜8.12が新規の管理策であることと、それぞれの概要を確認しました
• 個人情報の保護に関する法律についてのQ＆A（行政機関等編）（個人情報保護委員会） … 行政機関等が仮名加工情報を作成できないこと、地方公共団体の機関が行政機関等匿名加工情報の仕組みを扱うことを確認しました
• 岡田敏靖『ISO27001:2022の規格と審査がしっかりわかる教科書 改訂2版』（技術評論社） … 連載で使っている教科書です。35節（A.8）のうちA.8.7〜A.8.12の説明を読みました。2013年版の番号は、付録の対応表（27002:2022の附属書Bをもとに作成、と注記あり）から引いています

引っかかった点

教科書のA.8.9の説明は、構成管理を環境の情報を最新に保つことと説明し、対象に契約情報やベンダー情報まで挙げていました。管理基準の細目の中心は、セキュリティを保った構成の標準テンプレートと、実際の構成との比較です。記事では、強調点の違いとして書き、細目の語で整理しました。

教科書のA.8.7の説明では、対策ソフトを導入し、定義ファイルを常に最新に保つことが「必須」とされていました。管理基準の細目では、対策ソフトの導入と更新は考慮する事項の1つで、単独では通常十分でない、と添えられています。教科書の「必須」は、実務上の強調として読みました。

教科書のA.8.11の説明には、本人からの要求で難読化を受け付けるルールを定める、という項目がありました。管理基準の細目は、難読化していること自体を利用者が知ることができないよう、本人が求められるようにする、という書き方です。参考には「難読化の難読化」とありました。向きが違って見えるので、記事では管理基準の語に寄せています。

同じくA.8.11で、教科書は個人情報保護法の仮名加工情報と匿名加工情報を使って説明していました。これは民間の事業者向けの定めです。個人情報保護委員会のQ&A（行政機関等編）によると、行政機関等には仮名加工情報の作成の規定が適用されず、仮名加工情報を作ることはできません。匿名加工についても、行政機関等には「行政機関等匿名加工情報」という別の仕組みがあります。記事では法令の加工の定めには立ち入っていません。自治体の読者は、自分に当たる定めを委員会の資料で確かめてください。

JNSAの解説資料は、A.8.10の目的を、機器・装置の廃棄の段階での情報漏えいの防止と説明していました。管理基準の細目は、運用中の古い版や一時ファイル、第三者に預けた情報まで並べています。記事では細目の範囲で書きました。

技術的順守のレビュー（A.18.2.3）が、A.8.8の細目のどこに着地したかは、管理基準にも教科書にも書かれていません。スキャンツールと侵入テストの細目にあたる、というのは筆者の読みです。