連載「ISMS審査員・監査への道」の第23回です。前回で、物理的管理策（A.7）を読み終えました。
今回から、4つ目のテーマ、技術的管理策（A.8）に入ります。34個と、4テーマの中で2番目に大きな山です。経済産業省の情報セキュリティ管理基準は、これを4つに区切っています。今回はその最初の区切り、「情報アクセスの管理」にあたるA.8.1〜A.8.6の6個を読みます。
これまでと同じく、附属書Aの管理策の文と、管理基準が挙げる詳細管理策（以下、細目）は分けて書きます。細目はISO/IEC 27002をもとにした実施の手引です。多くは「考慮する」事項として並んでいます。
- A.8.1〜A.8.6の6個が、2013年版のどこから来たか
- 2013年版のアクセス制御が、組織的管理策と技術的管理策に分かれたこと
- 利用者エンドポイント機器の対象が、席にいる人のパソコンまで広がったこと
- 特権的アクセス権は、一般のIDと違って共有しない書き方になっていること
- ソースコードを持たない組織が、A.8.4をどう読むか（管理策の文と細目の違い）
- 容量・能力の管理の手引が、システムだけでなく人とオフィスまで挙げていること
A.8.1〜A.8.6をひとことで言うと——使う機器と、入るための鍵と、足りるかどうか
ひとことで言うと、情報に「誰が、何で、どこまで」触れるかを、技術の側で固める6個です。最後のA.8.6だけ毛色が違い、資源が足りているかを見張る管理策になっています。
| 番号 | 管理策 | ひとことで | 2013年版 |
|---|---|---|---|
| A.8.1 | 利用者エンドポイント機器 | 利用者が使う端末と、その中の情報を守る | A.6.2.1、A.11.2.8 |
| A.8.2 | 特権的アクセス権 | 管理者の権限を絞り、見張る | A.9.2.3 |
| A.8.3 | 情報へのアクセス制限 | 方針どおりに、触れる範囲を制限する | A.9.4.1 |
| A.8.4 | ソースコードへのアクセス | ソースコードや開発ツールへの読み書きを管理する | A.9.4.5 |
| A.8.5 | セキュリティを保った認証 | 情報の重さに合った本人確認を備える | A.9.4.2 |
| A.8.6 | 容量・能力の管理 | 資源の使い方を見張り、足りるよう調整する | A.12.1.3 |
6個に、2022年版の新規はありません。元になったのは2013年版の7個です。A.8.1に2個がまとまったぶん、1つ減りました。
A.8.1に入った2個のうち、A.11.2.8は第21回と前回で「A.7ではなくA.8.1へ移った」と書いたものです。ここで行き先がつながりました。
2013年版のアクセス制御は、2か所に分かれた
表の2013年版の列を見ると、A.8.2〜A.8.5の4個がA.9から来ています。A.9は「アクセス制御」という箇条で、14個の管理策がありました。
その14個の行き先を数えてみました。9個は組織的管理策のA.5.15〜A.5.18へ、5個は技術的管理策のA.8へ移っています。
| 行き先 | 2022年版の管理策 | 2013年版から来た数 | 性格 |
|---|---|---|---|
| 組織的管理策（A.5） | A.5.15 アクセス制御／A.5.16 識別情報の管理／A.5.17 認証情報／A.5.18 アクセス権 | 9個 | 規則を決め、IDと権限を渡し、見直す |
| 技術的管理策（A.8） | A.8.2 特権的アクセス権／A.8.3 情報へのアクセス制限／A.8.4 ソースコードへのアクセス／A.8.5 セキュリティを保った認証／A.8.18 特権的なユーティリティプログラムの使用 | 5個 | 決めた規則を、仕組みで効かせる |
決め事がA.5に、それを効かせる仕組みがA.8に置かれた。筆者はそう読みました。実際、A.8.2・A.8.3・A.8.5の細目は、どれも「アクセス制御に関するトピック固有の方針に従って」と書き、A.5.15を参照しています。A.8側だけを読んでも、何に従うのかは分かりません。A.5の側は第17回で読んでいます。
A.8.1 利用者エンドポイント機器——席にいる人のパソコンも入った
A.8.1は、利用者エンドポイント機器に保存された情報、そこで処理される情報、そこからアクセスできる情報を守る管理策です。
エンドポイント機器とは、利用者が手元で使う端末のことです。デスクトップ、ノートパソコン、スマートフォン、タブレットなどが当たります。
2つの管理策がまとまって、対象が広がった
JNSAのセミナーで、SC 27 WG1の国内委員会の委員が、27002の2022年版の改定を解説した資料があります。そこでは、A.8.1は「対象範囲の拡大」の例に挙がっていました。
2013年版のA.6.2.1は持ち運ぶモバイル機器の方針、A.11.2.8は無人の状態にある装置の保護でした。この2つをまとめ、人が座って使っている最中のデスクトップも対象にした、という説明です。特別な場面として扱っていた2つが、端末全般の管理策に吸収されたことになります。
細目は、方針の中身を15項目で挙げる
細目の出発点は、端末の扱いについてトピック固有の方針を決めることです。考慮する事項として、情報の分類、端末の登録、インストールの制限、更新、暗号化、遠隔での消去、USBポートなど15の項目が並びます。
目を引いた細目は2つでした。1つは、特に慎重に扱う情報について、端末からアクセスはできても保存はできないようにするかを検討する、というものです。見せることと、置かせることを分けています。もう1つは、推奨事項を、可能な限り構成管理や自動化されたツールで強制する、というものでした。
A.8.1は、端末の守りを具体的に書くほど、その組織の守りの中身の説明になります。第21回のA.7.4と同じ理由で、ここは細目の紹介にとどめます。
A.8.2 特権的アクセス権——一般のIDと違い、共有しない
A.8.2は、特権的アクセス権の割当てと利用を、制限し、管理する管理策です。
特権的アクセス権とは、システムの設定を変えたり、他人のデータを見たりできる、管理者の権限のことです。悪用されたときの影響が大きいので、一般の利用者の権限とは別に扱います。
細目は12項目。3つが目を引いた
細目は、必要な利用者の特定から始まり、12の項目が考慮する事項として並びます。力量をもつ人にだけ最小限で与えること、認可と記録、終了、全ての特権的アクセスのログ、などです。
その中で目を引いたのは次の3つでした。
- 定期的に、また組織に何か変更があった後に、特権を使う利用者をレビューする
- 特権を永続的に許可するのではなく、承認された作業に必要な時間枠だけ一時的に許可する
- 特権をもつIDを複数の人で共有せず、各人に個別のIDを割り当てる
2つ目の細目には、これはしばしばブレークグラス手順と呼ばれる、と添えられていました。筆者の言葉で言えば、非常ボタンのガラスを割るように、必要な時だけ取り出す考え方です。
一般のIDは条件付きで共有できる。特権のIDは共有しない
3つ目は、第17回で読んだA.5.16と並べると、違いがはっきりします。
| 一般のID（A.5.16） | 特権をもつID（A.8.2） | |
|---|---|---|
| 共有 | 条件付きで認められる（業務上の理由・承認・文書化。筆者のまとめ） | 複数の人で共有しない。各人に個別のIDを割り当てる |
| 汎用の管理者ID（rootなど） | — | 使用を避けるための規則を決め、その認証情報を守る |
同じIDの話でも、特権の側は一段厳しく書かれています。誰がその操作をしたのかを、後からたどれるようにするためだと筆者は読んでいます。全ての特権的アクセスのログを取る細目も、個別のIDがあって初めて意味を持ちます。
現場から：特権は、いつも手元にある
筆者の現場では、管理者の権限はいつも手元にあります。作業のたびに権限を受け取る形ではありません。
細目の2つ目、必要な時間枠だけ一時的に与える形とは違います。ただ、これを緩さとは考えていません。運用の現場には、障害の一次対応のように、権限を受け取るのを待っていられない場面もあります。細目も、一時的な付与は特権的アクセス管理の技術で自動化されることが多い、と添えています。仕組みを入れて初めて回る形なのだと思います。
整理して見えてきたのは、筆者の現場で絞られているのが「権限」ではなく「作業」だということでした。第6回で書いたとおり、作業の責任は筆者にあり、決めるのは職員です。第19回のソフトウェアの導入も、可否は職員が判断し、作業を筆者が受け持つ形でした。権限を使ってよいかどうかの手前で、何をするかが決まっています。
| 絞る場所 | 細目の書き方 | 筆者の現場 |
|---|---|---|
| 権限を持つ時間 | 必要な時間枠だけ一時的に与える | いつも手元にある |
| 何をするか | 承認された変更又は活動に使う | 職員が決め、筆者が作業する |
| 後から見直す | 定期的に、また組織の変更の後にレビューする | アクセス権は、組織変更のときにまとめて見直すことが多い（第17回） |
常に持つ形を選ぶなら、問われるのは表の3行目だと考えています。誰がいま特権を持っていて、それが今も必要か。前述の通り、第17回では、アクセス権をまとめて見直すのは組織変更のときが多い、と書きました。細目の「組織に何か変更があった後に」は、ちょうどこの形です。組織が変わらない年の拾い方は、第17回と同じく確かめていません。
A.8.3・A.8.5 触れる範囲を絞り、入口で本人を確かめる
A.8.3とA.8.5は、並べて読むと分かりやすいと感じました。前者は、入った後にどこまで触れるか。後者は、入る時に本人かどうかを確かめる管理策です。
A.8.3 情報へのアクセス制限——アプリの機能から、情報全般へ
A.8.3は、情報とその他の関連資産へのアクセスを、アクセス制御のトピック固有の方針に従って制限する管理策です。
2013年版のA.9.4.1は、情報とアプリケーションシステムの機能へのアクセス制限でした。JNSAの資料は、A.8.3を「対象が広がった管理策」の例に挙げています。アプリの機能に限らず、情報と関連資産の全般に広げた、という説明です。
細目は、読出し・書込み・削除・実行の権限の制御や、慎重に扱うシステムの隔離などです。価値の高い情報には、誰が、いつまで、どう触れるかを細かく制御する動的アクセス管理の採用を検討する、という細目もありました。
A.8.5 セキュリティを保った認証——強さは、情報の分類で選ぶ
A.8.5は、セキュリティを保った認証の技術と手順を、アクセス制限とアクセス制御の方針に基づいて備える管理策です。
細目で一番大事だと感じたのは、認証の強さを、アクセスする情報の分類に合わせて選ぶ、という一文でした。重要な情報システムには追加の認証要素を加える、とも書かれています。いわゆる多要素認証です。
ここで、第17回の話とつながりました。筆者の現場では、「社外秘」の表示は見えても、どれに付けるかの物差しは聞かない、と書いたものです。A.8.5を読むと、分類の物差しはラベルのためだけのものではありません。認証の強さを選ぶ根拠にもなっています。
ログオンの手順にも12の細目があります。意外だったのは、ログオンに成功したら前回の日時と、その後の失敗の詳細を表示する、という細目でした。自分のIDで誰かが試していたら、本人が気づける仕組みです。
パスワードの定期変更は、前述の通り、第17回で扱いました。A.8.5の細目にも、定期変更という言葉は見当たりませんでした。
A.8.4 ソースコードへのアクセス——コードを持たない組織はどう読むか
A.8.4は、ソースコード、開発ツール、ソフトウェアライブラリへの読取りと書込みのアクセスを、適切に管理する管理策です。目的として、認可されていない機能の混入と、意図しない変更を防ぎ、価値の高い知的財産の機密性を守ることが挙がっています。
細目は、役割に応じて読取りと書込みを分けて制限する、という考え方が軸です。参考の欄には、読取りは組織内で広く認めても、書込みは限られた人に絞る、という例がありました。変更は変更管理（A.8.32）に従い、全てのアクセスと変更を監査ログに残します。
細目は、コードに関連する書類も挙げている
読んでいて目が留まったのは、細目の最初の一文でした。厳重に管理する対象として、ソースコードと開発ツールに加え、関連書類が挙がっています。例は、設計書、仕様書、検証計画書、妥当性確認計画書でした。
ここは、管理策の文と細目を分けて読む必要があります。管理策の文が挙げるのは、ソースコード、開発ツール、ソフトウェアライブラリです。設計書や仕様書は、管理策の文には出てきません。コードに関連するものとして、細目の側で挙がっている、という関係です。
教科書は、ソースコードにアクセスできない組織なら、この管理策は採用しないことになる、と説明しています。適用宣言書（第8回）で除外する、という扱いです。
現場から：コードは開発の委託先にある
筆者の現場では、業務システムのソースコードは開発の委託先の側にあります。組織の手元にはありません。
教科書の説明に当てれば、A.8.4を外す理由がそろっているように見えます。ただ、細目が挙げるものを置き場所で並べ直すと、手元に残るものもありました。
| 細目が挙げるもの | ある場所 | 組織の側の手段 |
|---|---|---|
| ソースコード、開発ツール、ライブラリ | 開発の委託先 | 契約と、外部委託による開発の管理（A.8.30） |
| 関連書類（設計書、仕様書など） | 発注する組織にも残る | 組織自身のアクセス制御 |
コードの側は、組織が直接は触れません。代わりに効くのは、委託先にどう管理させるかを決める契約です。第12回で、納品後の機器やソフトは保守契約で見ている、と書きました。開発のコードも、同じく契約が管理の器になる側だと考えています。附属書Aには、そのための管理策としてA.8.30（外部委託による開発）があります。細目は第27回で読みました。
書類の側は、事情が違います。仕様書は、発注する側が書いて委託先に渡すものです。つまり、コードを持たない組織の手元にも、そのシステムの設計の考え方は残っています。
ここから、筆者の整理です。コードが委託先にあることだけで、A.8.4の扱いが決まるわけではないと考えています。手元の仕様書や設計書を誰が読めるか、委託先のコードをどう管理させているか。適用宣言書で採否を説明するときは、コードの所在に加えて、こうした点をリスク対応の中でどう扱ったかまで言えるようにしておくとよいと思います。
A.8.6 容量・能力の管理——手引では、人とオフィスも「容量」
A.8.6は、現在と将来の容量・能力の要求に合わせて、資源の利用を監視し、調整する管理策です。
容量と聞くと、ディスクやメモリ、回線の太さを思い浮かべます。筆者もそうでした。ところが、管理基準の目的の欄には、情報処理施設、人的資源、オフィスその他の施設、と並んでいます。管理策の文そのものは「資源」としか書いていません。人やオフィスが具体的に出てくるのは、目的と細目の側です。
JNSAの資料も、A.8.6を「対象が広がった管理策」に挙げていました。システムの容量・能力だけでなく、施設・人的資源・オフィスまで含めた手引に拡充した、という説明です。
細目は、増やすだけでなく減らす手も挙げる
細目は、重要度に応じた要求の特定、調整と監視、負荷テスト、問題を早めに知らせる検知、将来の予測、と進みます。
足りなくなったときの手当ては2通りでした。増やす側には、人を雇う、場所を得る、機器を強くする、クラウドを使う、が並びます。減らす側には、古いデータの削除、保存期間を過ぎた紙の処分、使わないシステムの廃止などが並びました。
特に目を引いたのは、資源の制約と、主要な要員への依存の度合いを特定して避けるために、容量・能力の情報を使う、という細目です。特定の人しか分からない状態を、容量の問題として扱っている書き方でした。手に入れるまでに長い期間か高い費用がかかる資源には特別な注意を払う、という細目もあります。
現場から：気づくのは常駐のSE、決めるのは職員
ディスクの容量や、ライセンスの数、人手が足りなくなりそうなとき。筆者の現場で最初に気づくのは、常駐のSEです。職員に報告し、指示があれば対応します。
細目の流れに当てると、役割はきれいに分かれていました。
| 細目の段 | 筆者の現場 |
|---|---|
| 問題を早めに知らせる検知 | 常駐のSEが気づく |
| 増やすか、減らすかの判断 | 報告を受けた職員が決める |
| 調整の作業 | 指示があれば、常駐のSEが対応する |
前回の、機器のある部屋のカビと同じ形です。気づく位置にいる人が気づき、持ち主の側が決める。容量でも、この分担は筋が通っていると考えています。増やすには時間とお金がかかることが多く、予算の判断と切り離せないからです。
そのうえで、細目と並べて気になった点が2つあります。
1つは、将来の予測です。報告は、足りなくなりそうだと気づいた時点で上がります。1件ずつの報告を束ねて、来年や次の更新でどれだけ要るかを見積もる材料に使えるか。第13回で書いた、集計は報告に出したら役目が終わる、という話と同じ形の問いです。ここは確かめていません。
もう1つは、気づく人そのものが容量だという点でした。細目は、主要な要員への依存の度合いを特定する、と書いています。筆者の現場では、検知の段を常駐のSEの目が受け持っています。細目のこの観点から、筆者は、その目がどれだけの範囲を見られるかも容量・能力の一部として考えられる、と読みました。第10回で、足りないと感じるのは人手より知識だと書いたこととも重なります。
よくある落とし穴／審査で指摘されやすい点
A.8だけ読んで、従う方針（A.5.15）を忘れる
A.8.2・A.8.3・A.8.5の細目は、アクセス制御の方針に従うことが前提です。仕組みが従う決め事を示せないと、説明が途中で切れてしまいます。
特権のIDを、一般のIDと同じ感覚で共有する
A.5.16は、共有のIDを、業務上必要な場合に承認と文書化のうえで認めています。特権をもつIDは、細目で共有しない書き方です。「昔からみんなで使っている管理者ID」は、指摘されやすい箇所だと考えています。
いつも持っている特権を、数え直していない
常に持たせる形を選ぶなら、そのぶん、誰がいま持っていて今も要るのかを見直した跡が問われます。見直しが組織変更のときだけなら、変わらない年の扱いを説明できるようにしておきたいところです。
ソースコードが無いことだけを理由に、A.8.4を外す
細目は、コードに関連する設計書や仕様書も挙げています。コードが委託先にあっても、手元の書類の扱いと、委託先にどう管理させているか（A.8.30）は、説明を求められることがあると考えています。
容量を、機器の数字だけで考える
管理基準のA.8.6の目的と細目には、人的資源とオフィスが並んでいます。気づく人が一人に寄っている状態も、容量の問題として見られることがあります。
まとめ
- A.8.1〜A.8.6の6個は、管理基準で「情報アクセスの管理」にまとめられています。元は2013年版の7個で、新規はありません。2013年版のアクセス制御（A.9）の14個は、組織的管理策へ9個、技術的管理策へ5個に分かれました
- A.8.1は、持ち出す機器と無人の機器の2つをまとめ、使用中のデスクトップまで対象を広げました
- A.8.2の細目は、特権をもつIDを共有しないこと、必要な時間枠だけ一時的に許可することを、考慮する事項に挙げています。筆者の現場では特権はいつも手元にあり、何をするかを職員が決める形で絞られています
- A.8.4の管理策の文はソースコードと開発ツールを挙げ、細目は設計書や仕様書などの関連書類も挙げています。筆者の現場ではコードは開発の委託先にあり、手元に残るのは書類の側です
- A.8.6の目的と細目では、システムだけでなく、人とオフィスの容量・能力も挙がっています。筆者の現場では、常駐のSEが気づき、職員が決めています
次回は、技術的管理策の2つ目の区切り、情報資産運用に関する管理の前半（A.8.7〜A.8.12）を読みます。
連載の入口は第1回です。
参考にした一次資料
- 経済産業省「情報セキュリティ管理基準（令和7年改正版）」 … 管理策基準の8a（8.1〜8.6）の管理策・目的・詳細管理策を読みました。A.5.17の細目も照合しています。JIS Q 27001:2023、JIS Q 27002:2024をもとにした版です。本文は意見公募時に公開されていた版から読んでいます
- 情報セキュリティマネジメント・セミナー2022 講演資料（JNSA 日本ISMSユーザグループ／2022年12月16日） … 「ISO/IEC 27002 改定の解説」（土屋直子／NTTテクノクロス）で、8.1が6.2.1と11.2.8の統合で対象を広げたこと、8.3と8.6が対象の広がった管理策であることを確認しました
- 岡田敏靖『ISO27001:2022の規格と審査がしっかりわかる教科書 改訂2版』（技術評論社） … 連載で使っている教科書です。35節（A.8）のうちA.8.1〜A.8.6の説明を読みました。2013年版の番号は、付録の対応表（27002:2022の附属書Bをもとに作成、と注記あり）から引いています
引っかかった点
教科書のA.8.2の説明では、特権的IDを共有する場合は、パスワードを頻繁に変更するなどの対策を実施する、となっていました。管理基準の細目は、特権をもつIDを複数の人で共有せず、各人に個別のIDを割り当てる、です。向きが逆に見えます。記事では管理基準の語で書きました。教科書の書き方が2013年版の手引から来ているのかは、手元の資料では確かめていません。
同じくA.8.2の説明で、特権の割当てが従う方針として「附A.9.1.1」が挙がっていました。2013年版の番号です。2022年版では、アクセス制御の方針はA.5.15にあたります。
教科書のA.8.3の説明は、個々の情報やアプリケーションシステムの機能へのアクセスを制御する、という書き方でした。JNSAの資料は、A.8.3をアプリの機能から情報全般へ対象を広げた管理策として紹介しています。記事では管理基準とJNSAの資料に沿って書きました。
教科書のA.8.1の説明には、「ゼロトラスト」を基本とした方針を策定する、とありました。管理基準のA.8.1の細目に、この語は見当たりません。教科書の説明として読み、規格の要求としては書いていません。
教科書のA.8.5の図には、パスワードの定期的な変更が入っていました。A.8.5の細目には見当たりません。第17回で書いたとおり、A.5.17の細目も、変えさせる場面を「必要に応じて」と書いています。