そのルールでセキュリティ担当者は動ける？——方針・基準・手順・例外・新しいIT・ドメイン名の管理を午後の問われ方で読む｜支援士解説1の4

この記事の重要度：Bランク（午後では小問や問題文の前提として問われる分野。用語は午前II（科目A-2）でも問われる）

この記事で分かること：

• 基本方針・対策基準・実施手順・記録の役割の違いと、業務の流れから規程を作る手順

• 担当者が動ける文章にする条件（主体・期限・確認・例外）と、新しいIT・生成AIで見直す点

• ドメイン名・DNS・証明書の管理と、規程の見直しの進め方

シラバスとの対応：小項目1-4「情報セキュリティ諸規程の策定」。方針の策定は支援士解説1の1、法令と契約は支援士解説3の11、事業継続（BCP）とバックアップは支援士解説3の3、DNSの仕組みは支援士解説3の5で扱います。

「利用権限を適切に管理する」と規程に書いてあります。それでも、異動した職員の古い権限が半年残っていました。誰が、いつまでに、何を確かめて、どこに記録するかが決まっていなかったからです。規程は、立派な文章を作ることではなく、担当者が迷わず動けて、動いたことを後から確かめられる状態を作ることです。

午後の問題では、規程の見直しで申請書に何を書かせるか、診断の結果からガイドラインに何を足すか、ライブラリの入手をどうルールにするか、使わなくなったサブドメインのDNSの設定をどう直すかが問われます。この記事では、文書の階層、規程の作り方、文章の書き方、新しいIT、ドメイン名の管理、生成AI、事業継続、見直しの順に要点を整理します。

1. 方針・基準・手順・記録をつなぐ

規程の文書は、役割の違う四つを組み合わせます。架空の申請サービスで、異動に伴う利用権限の変更を例にします。

• 基本方針：組織として何を大切にするか。「申請情報を適切に保護し、必要な業務を継続する」のように、目指す方向と姿勢を示す。画面の操作までは書かない

• 対策基準：方針を実現するために守るべき事項。「業務に必要な権限だけを付与する」「不要になった権限を削除する」「変更と確認を記録する」のように、製品に依存しない形で書く

• 実施手順：担当者が作業できる具体的な方法。「所属の担当者が異動の情報を通知し、業務責任者が承認し、管理担当が変更し、別の確認担当が結果を確かめて記録する」のように、期限、様式、代理の担当まで決める

• 記録：実際に何をしたかの証拠。手順書があっても、権限が変更された証拠にはならない。依頼、承認、変更の日時、結果の確認を結び付ける

方針が操作説明ばかりなら、製品が変わるたびに組織の姿勢まで書き換えることになります。逆に方針しかなければ、何をするかは担当者任せになります。

三つの階層の名前と構成は、組織の制度に合わせます。総務省の自治体向けガイドラインでは、基本方針と対策基準を合わせて「情報セキュリティポリシー」と呼び、実施手順はそれを業務に落とし込むものと位置付けています。民間では、ポリシーを基本方針だけの意味で使うこともあります。公開する範囲も、文書の名前ではなく、内容の機密性と説明の必要性で判断します。基本方針は外部に示すことが多い一方、管理画面の構成や緊急時の連絡先を誰にでも見せてよいわけではありません。

ISMSでは、こうした文書と記録を「文書化した情報」として管理します。作成と更新の承認、必要な人が使える状態、改ざんや紛失からの保護、変更の管理、保存と廃棄を決めます。記録も、保存する期間と、誰が閲覧できるかを決めておかなければ、必要なときに使えません。

記述の型

• 実施手順に書くこと：「誰が、何を契機に、何を、いつまでに行い、誰が確認して、何を記録するか」

• 手順と記録の違い：「手順はこれから行うことを、記録は実際に行ったことを示す」

2. 業務の流れから、規程を具体化する

ひな形は参考になりますが、何の業務に使うかが分からなければ、書くべき内容は決まりません。まず、受付、審査、通知、保存、廃棄という業務の流れを書き出し、各段階で、誰が情報を扱うか、何を扱うか、どこへ移るか、何が起きると困るか、誰が判断するかを確かめます。審査のためにデータを表計算のファイルに出力する工程があるなら、サービスの中の権限だけでは足りず、出力先、閲覧者、再配布、保存期間、削除が規程の対象になります。

リスクの分析では、何が起こり得て、どの程度困るかを考えます。要求事項の確認では、法令、契約、組織の方針によって何を満たす必要があるかを確かめます。保存する必要があることと、誰でも閲覧できることは別の判断です。法令、規格、国の基準、契約は、適用の対象と位置付けがそれぞれ違うので、同じ扱いにしません。内部の規程を変えても、契約の相手の作業は変わらないので、委託先の作業を変えるなら契約と分担も確かめます。

見直しやすくするには、次を一組で記録しておきます（本稿の提案）。

• 要求の出所と版（法令の条項、基準の節、契約の条項）と、対象の業務・情報

• 自組織に求められる内容と、その解釈を確かめた担当

• 対応する規程・手順・契約の箇所

• 実施する担当と、実施を確かめる記録

• 法改正や契約の更新など、確かめ直す契機

出典の一覧だけでなく、どの業務にどう当てはめたかを残すことがポイントです。

ISO/IEC 27001は、情報セキュリティを管理する仕組み（ISMS）に対する要求事項の規格、ISO/IEC 27002は、管理策の実施の手引です。管理策は、組織的・人的・物理的・技術的の四つのテーマで整理されています。規程を作るときも、技術的な設定に偏っていないかを確かめる視点になります。例えば申請データの出力なら、技術面では権限を制限し、組織面では承認と委託先の分担を決め、人的な面では取扱いを教育し、物理面では印刷物の保管と廃棄を決めます。

記述の型

• 業務の流れから規程を作る：「受付から廃棄までの情報の流れを書き出し、段階ごとに担当・対象・保存先・承認者を決める」

• 保存と閲覧の区別：「保存の必要性と、閲覧できる範囲を分けて決める」

3. 担当者が動ける文章にする

「適切に」「速やかに」は方向を示しますが、作業の完了の条件にはなりません。例えば、次のように具体化します（期限と役割は架空の条件です）。

• 所属の連絡担当は、異動が確定した利用者を、原則として異動日の3営業日前までに管理担当へ通知する

• 業務責任者は、異動後に必要な権限を確かめ、変更を承認する

• 管理担当は、承認された変更を、異動日の利用開始までに反映する

• 確認担当は、変更の対象と結果を照合し、結果と日時を記録する

• 期限までに処理できなければ、管理担当が業務責任者へ報告し、暫定の対応を判断してもらう

ここまで決めれば、通知が届かなかったのか、承認が滞ったのか、操作に失敗したのかを切り分けられます。緊急の退職や不正利用の疑いでは3営業日を待てないので、通常の変更と緊急の停止を分けておきます。

規程を読むときは、次の七つの問いに答えられるかを確かめます。

1. 誰が行うか。不在のときは誰が代わるか

2. 何が対象か。情報、利用者、機器、委託先の範囲は明確か

3. 何が起きたら行うか（異動、契約の終了、設定の変更などの契機）

4. 何を、いつまでに行うか。できないときはどうするか

5. 誰が承認・確認するか。作業者と分かれているか

6. 何を記録するか

7. 例外を誰が判断するか

全てを一つの文章に押し込む必要はなく、対策基準、手順、申請の様式、役割の一覧に分けても、参照すれば一つの作業として読めればよいのです。役割の一覧では、作業ごとに、実行する人、最終的な責任を持つ人、相談を受ける人、結果を知らされる人を分けて書くと、抜けと重複が見つかります。

ルールには理由と代わりの手段も添えます。「個人のクラウドに保存してはいけない」だけでは、担当者は業務を終える方法が分かりません。組織が管理していない保存先では、退職後の利用の停止や誤った共有への対応を確かめられない、という理由を示し、承認された保存先と、外部と共有するときの申請の方法を示します。

例外は、基準どおりにできない場合に、権限のある者が条件付きで認める仕組みです。対象、理由、期間、代替の対策、残るリスク、改修の予定、許可した者を明確にし、期限が来たら確かめずに延長しないようにします。内部の例外の許可で、法令や契約の義務が消えるわけではありません。

午後での問われ方

• 令和4年度春期 午後II問1：アジャイル開発を行う企業のWebサイトが題材でした。開発部のメンバがそれぞれライブラリを集めて共有のファイルサーバに置いて使っていたところ、既知のXSSの脆弱性を直していない版が使われ、複数のサイトで同じ脆弱性が見つかりました。再発防止策として、解答例には「ダウンロードするライブラリに既知の脆弱性がないかを確認する。」と「特定のWebサイトからの入手をルール化し、明文化する。」が示されています。各人の慣習に任せていた作業を、ルールとして書いておくことが答えになっています。

記述の型

• 規程の具体化：「（担当）は、（契機）から（期限）までに（作業）を行い、（確認者）が結果を確かめて記録する」

• 例外の管理：「対象・理由・期間・代替策・許可者を定め、期限が来たら継続の要否を判断し直す」

4. 新しいITで、管理のどこが変わるか

新しい技術が出るたびに、名前を禁止の一覧に足すのでは追いつきません。情報の置き場所、作業の担当、接続先、変更の方法がどう変わるかを考えます。

• クラウド：提供の形態と契約で、利用者と事業者が管理する範囲が変わる。SaaSでも、管理者権限を誰に与えるか、何を登録するか、共有をどう設定するかは利用者が決める。利用の承認の条件、扱える情報、権限、設定の変更、操作の記録、事故時の連絡、契約終了時のデータの取出しと削除を規程にする。第三者の評価の報告書は、対象のサービスと範囲を読んで使う（支援士解説2の2）

• 仮想化：仮想マシンを複製すると、設定やデータ、認証情報も複製される。本番を複製して試験に使うなら、個人情報や接続先が残っていないかを確かめる。作成の承認、台帳への登録、保存期限、廃棄を決め、基盤全体を操作する権限を個々の仮想マシンの権限と分ける

• モバイル：持ち出した後の利用と、紛失したときの連絡、アカウントの停止、遠隔消去を決める。私物の端末を使うBYODでは、私的な情報との分離と、利用を終えるときの扱いも決める

• Web：公開の承認、更新、脆弱性への対応、緊急時の停止を決める。公開ページに内部の資料を添付すれば、案内を直しても、取得された情報は戻らない。Web APIは画面を操作しなくてもデータが移るので、連携先、認証情報、実行できる操作、利用終了時の停止を決める

• シャドーIT：部署や個人が、組織の承認を受けずにクラウドサービスや機器を使うこと。禁止を書くだけでは減らないので、承認されたサービスの一覧と、新しいサービスを申請する簡単な手続を用意し、利用状況を可視化する仕組み（CASBなど）と組み合わせる

• 組込みシステム・IoT：更新による再起動が、現場の安全やサービスに影響することがある。「更新は全て直ちに自動で適用」とだけ決めても実施できない場合がある。機器の所在と責任者、接続先、保守の接続、停止できる時間、サポートの期限を把握し、更新できないなら接続の制限、監視、交換の計画を決める

記述の型

• 仮想マシンの複製の注意：「複製した環境にも、本番の個人情報や認証情報が残る」

• クラウドの規程：「利用者が管理する範囲（権限、共有の設定、登録する情報）を規程に定める」

5. ドメイン名・DNS・証明書の管理を規程にする

組織のドメイン名は、Webサイト、メール、外部サービスとの連携の土台です。管理が担当者任せになりやすく、規程の抜けが事故につながります。次を決めておきます。

• 登録と更新：どのドメイン名を、どの登録事業者（レジストラ）で、誰の名義で登録しているか。更新の期限と、期限を知らせる連絡先。担当者の個人のメールアドレスを連絡先にしていると、異動や退職で通知が届かなくなる。期限切れで失効したドメイン名を第三者に取得されると、そのドメイン名でサイトやメールを運用される

• 管理アカウント：レジストラとDNSの管理画面のアカウントを、組織として管理する。多要素認証を使い、操作できる人を限る。DNSの設定を書き換えられれば、Webもメールも乗っ取られる

• DNSレコードの棚卸し：どのサブドメインを、どのサービスに向けているかを台帳にする。サービスの利用を終えたら、CNAMEなどのレコードも削除する。外部のサービスを向いたまま残ったレコードは、第三者にそのサービス側で同じ名前を登録され、サブドメインを乗っ取られる原因になる（サブドメインテイクオーバー）

• 証明書：サーバ証明書の発行を申請できる人、期限、更新の手順を決める。期限が切れたからといって、検証を無効にして通信を通す応急処置をしない

• 登録者の情報：ドメイン名やIPアドレスの登録者の情報（組織名、担当の部署、担当者）は、公開されている範囲でWHOISなどで誰でも調べられる（ドメインの種類によっては非公開にできる）。担当者が替わったら更新し、問合せや通知を受け取れる窓口にしておく

• 利用の開始と終了：部署が独自にドメイン名やクラウドのサービスを契約すると、組織が把握しない公開の資産が生まれる。取得と利用の終了を、情報システム部門に届け出る手続にし、IT資産の台帳にドメイン名とグローバルIPアドレスも載せる

DNSの仕組みとサブドメインテイクオーバーの技術的な説明は支援士解説3の5、証明書の検証は支援士解説3の1で扱います。

午後での問われ方

• 令和7年度春期 午後問4：IT資産管理と脆弱性管理の改善が題材でした。使用を終えたCDNサービスやWebサーバを指すDNSのレコードが残っていて悪用された事象への対策として、解答例は、権威DNSサーバで「終了したサブドメインのCNAMEレコードを削除する。」です。IT資産管理台帳の規程では、事業部が他社のデータセンター、クラウドサービス、レンタルサービスを契約して使うサーバは台帳に登録されず、ドメイン名も各事業部が取得していました。こうした未把握の公開IT資産を見つける場面で、空欄には「レンタルサービスを契約して利用した」「他社データセンターを契約して利用した」が入り、ドメイン名の登録者の情報を調べる手段として「WHOIS」が問われました。台帳と届出の規程の抜けが、そのまま攻撃の入口になった例です。

採点講評で指摘されたつまずき

• 令和7年度春期 午後問4では、DNSサーバの設定の変更を問う設問の正答率が低かったとされています。本文の事象が、使用終了後のCNAMEレコードの削除漏れによるサブドメインテイクオーバーであると理解したうえで、具体的な対策を答えることが求められています。

記述の型

• 利用終了時の措置：「サービスの利用を終えたら、そのサービスを指すDNSのレコードを削除する」

• 未把握の資産を防ぐ：「部門がドメイン名やサービスを契約・終了するときは、情報システム部門への届出を必須とし、台帳に登録する」

6. 生成AIとデータ活用は、入力・出力・連携・結合を分ける

AIの利用は、文章の生成だけではありません。問合せの分類や需要の予測にも使われます。規程では、利用の目的、使うデータ、結果を判断に使う範囲、異常があったときの停止と代わりの手段を決めます。同じ仕組みでも、担当課の提案に使うのと、利用者の権利や給付に関わる決定に使うのとでは、必要な確認が違います。

• 入力：そのサービスを業務に使ってよいか、どの区分の情報を入力してよいか、入力した内容が保存や学習に使われるかを、契約と設定で確かめる。法人向けという名前だけで条件は決まらない。学習への利用を制限できても、送信先や保存先の確認は要る

• 出力：読みやすい文章でも、期限や対象の条件が正しいとは限らない。公開する前に、業務の担当が公式の案内や規程と照合する。「人が確認する」と書くだけでなく、事実、数値、引用先など、何を確かめるかを示す

• 連携：AIが文書を検索したり、外部のシステムを操作したりするなら、検索の対象と利用者ごとの閲覧権限を確かめ、参照だけの権限と、送信や更新をする権限を分ける。影響の大きい操作は、実行の前に人が確かめ、結果を記録する。AIが読み込んだ文書やWebページに仕込まれた指示に従って、意図しない操作をしてしまう攻撃（プロンプトインジェクション）もあるので、AIに与える権限は必要な範囲に絞る

• データの結合：氏名を除いた記録でも、少人数の属性や時刻を組み合わせれば、個人に結び付くことがある。利用の目的、項目、結合するデータ、閲覧者、結果を外に出すときの確認を決める

新しい機能で情報の流れや判断の責任が変わるなら、規程も見直します。

記述の型

• 生成AIの出力の確認：「公開する前に、担当者が事実・数値・条件を公式の資料と照合する」

• 入力の制限：「入力してよい情報の区分と、業務に使えるサービスを定める」

7. 非常時の規程：BCPとBCMの位置付け

BCP（事業継続計画）は、大きな支障が起きたときに重要な業務を続け、必要な水準まで戻すための計画、BCM（事業継続管理）は、計画の策定に加え、体制と資源の整備、教育と訓練、点検、改善を続ける管理の仕組みです。BCPの文書を作って保管するだけでは、BCMができているとは言えません。業務への影響を時間とともに分析するBIA、目標のRTO・RPO・RLO、災害復旧の拠点の考え方は支援士解説3の3で扱います。

BIAでは、業務が止まったときの悪影響が許容できなくなるまでの時間をMTPD（最大許容停止時間）として考えます。RTOは、確認の遅れや処理の滞留に備えて、MTPDより短く置きます。RTOを決めても、その時間で戻せるとは限らないので、訓練で確かめます。

規程の観点では、非常時に通常の手続が使えない場面を先に決めておきます。紙で受付を続けるなら、切り替える判断者、仮の受付番号、保管と受渡し、システムへの転記と重複の確認まで手順にします。緊急用の権限を使うなら、使ってよい条件、認証情報の保管、使った人の特定、操作の記録、使った後の見直しを決めます。緊急の状態が終わっても強い権限が残れば、平常時の管理に戻れません。復旧の手順と連絡先が、止まったシステムの中にしかないという状態も避けます。

訓練には、想定した事態で関係者が判断と行動を確かめる机上の訓練と、データやシステムを実際に戻す復元の訓練があります。結果は成功か失敗かで終えず、誰の連絡先が古かったか、どの判断に時間がかかったかを記録し、担当と期限を決めて規程と手順を直します。

記述の型

• BCPとBCMの違い：「BCPは計画で、BCMは計画を訓練・点検・改善し続ける管理の仕組み」

• 緊急用の権限：「使用の条件、使った人と操作の記録、使った後の見直しを定める」

8. 規程は、見直して使い続ける

規程の作成を情報システム部門だけで完結させると、実際の業務の締切や例外が抜けます。業務部門だけで決めると、製品で実現できない制御を求めるかもしれません。業務部門は何を守りながら何を続けるかを、情報システム部門や委託先は実現の方法と制約を、法務は要求との整合を確かめ、責任者が権限に応じて判断します。

文書には、識別、版、適用開始日、承認者、変更内容を付け、現在有効な版に必要な人がたどり着けるようにします。「手順書_最終」「手順書_最終修正」のように版が増えると、どれが有効か分かりません。改訂を周知するときは、メールを送った事実と、理解して実施した状態を分けて確かめます。

見直しは、定期の確認と、重要な変化があったときの確認を組み合わせます。法令や契約の変更、新しいサービスの利用、委託先や組織の変更、インシデント・監査・訓練で見つかった問題、同じ例外の申請の繰り返しが契機です。改訂したら、申請の様式、設定、教育の資料、委託先の手順まで合わせ、開始後に未処理が残っていないかを確かめます。変更が不要と判断した場合も、確かめた事項と理由を残します。見直しの担当と時期を規程の中に書いておかないと、誰も見直さないまま年数がたちます。

午後での問われ方

• 令和元年度秋期 午後II問2：工場の標準PCがランサムウェアに感染し、感染を広げようとした痕跡が、工場が管理する生産設備の制御用のPCで見つかった。その制御用のPCは、部門の機器として全社のネットワークへの接続を許可されたまま、パッチの適用などの措置がされていなかった。この事案を受けた、セキュリティ規程の見直しが題材でした。規程には、接続の前にシステム部へ申請し、接続の目的、技術情報、管理者と連絡先を書面で出すことが定められていました。「各部門は機器とネットワークを管理・維持する措置を定める」「接続の申請の前にリスクアセスメントを実施する」という項目を加えるのに合わせて、申請の書面に追加する事項として、解答例は「各部門が定めた管理・維持のための措置」と「リスクアセスメントの結果」です。施策の実施状況とその効果を定期的に見直すプロセスを規程に明記することも検討されました。

• 平成30年度春期 午後II問2：Webサイトのセキュリティのガイドラインと、診断の内製化が題材でした。診断で見つかった脆弱性を踏まえてガイドラインを改善する方法として、解答例は「脆弱性の作り込み原因を調査して、注意すべきポイントを追加する。」です。

採点講評で指摘されたつまずき

• 令和元年度秋期 午後II問2では、申請の書面に追加する事項を問う設問の正答率が低く、ネットワークやシステムの運用に責任をもつ部署が知るべきことと、判断に必要な情報を理解しておいてほしいとされています。規程に項目を足したら、その結果を判断する部署に届く様式まで直します。

記述の型

• 規程の改訂に合わせる様式：「追加した義務の結果（定めた措置、リスクアセスメントの結果）を、申請の書面に記載させる」

• ガイドラインの改善：「見つかった脆弱性の作り込みの原因を調べ、注意すべき点として追加する」

9. 午前II（科目A-2）で正誤を見分けるポイント

• 「基本方針には、システムごとの具体的な操作の手順を記載する」→ 誤り。それは実施手順。基本方針は組織の方向と姿勢を示す

• 「対策基準は、方針を実現するために守るべき事項を定める」→ 正しい

• 「ISO/IEC 27001は、ISMSに対する要求事項を定めた規格である」→ 正しい

• 「ISO/IEC 27002は、ISMSの認証の審査の手順を定めた規格である」→ 誤り。管理策の実施の手引

• 「ISO/IEC 27002の管理策は、組織的・人的・物理的・技術的の四つのテーマで整理されている」→ 正しい

• 「例外を認めたら、期限を定めず継続してよい」→ 誤り。対象・期間・代替策を定め、期限に見直す

• 「BCMは、BCPの策定に加え、教育・訓練や改善を含む継続的な管理である」→ 正しい

• 「サービスの利用を終えた後も、そのサービスを指すCNAMEレコードは残しておいてよい」→ 誤り。サブドメインを乗っ取られる原因になる

• 「WHOISは、ドメイン名の登録者などの情報を調べるための仕組みである」→ 正しい

• 「規程を改訂したら、メールで送れば周知は完了する」→ 誤り。理解して実施できる状態まで確かめる

• 「シャドーITは、組織の承認を受けずに使われるITサービスや機器のことである」→ 正しい

• 「RTOは、MTPD（最大許容停止時間）より長く設定する」→ 誤り。許容できなくなる前に戻せるよう、短く置く

理解度チェック

本文の理解を確かめるためのオリジナル問題です。実際の過去問ではありません。

問1　文書の役割

実施手順に最も適した内容はどれか。

• ア：組織として情報を保護し、継続的な改善に取り組む姿勢

• イ：権限変更の申請の画面、承認の後の操作、結果を確かめる方法

• ウ：法令を守るという、組織全体の基本的な考え方

• エ：情報セキュリティを確保するという、経営上の方針

正解：イ。実施手順は、担当者が具体的な作業を行える内容にします。ア・ウ・エは基本方針で示す考え方に近く、それだけでは権限を変更できません。

問2　規程を作る順序

新しい申請サービスの取扱いの規程を作る。最も適切なものはどれか。

• ア：他団体の規程を、団体名だけ変えて採用する

• イ：利用する製品の説明書を、そのまま組織の規程とする

• ウ：業務と情報の流れ、リスク、適用される要求を確かめ、担当と実行の方法を具体化する

• エ：禁止事項をできるだけ増やし、例外は担当者の判断に任せる

正解：ウ。自組織の業務と要求から具体化します。エは、必要な業務と例外を判断する権限が不明になります。

問3　クラウドの利用

第三者の評価を受けたクラウドサービスを利用する。適切な対応はどれか。

• ア：評価を受けていれば、自組織での設定の確認は要らない

• イ：事故時の判断と利用者の権限の管理を、当然に事業者へ任せる

• ウ：評価の範囲を確かめず、名称だけで採用する

• エ：評価の対象・範囲と利用の条件を確かめ、自組織が管理する事項を規程に反映する

正解：エ。評価の資料は判断の材料ですが、自組織の利用の形態や担当まで決めるものではありません。

問4　生成AIの利用規程

公開する案内文の草案を、生成AIで作る。最も適切なものはどれか。

• ア：入力してよい情報を定め、公開の前に担当者が根拠と条件を確かめる手順を設ける

• イ：文法が正しければ、内容の確認を省く

• ウ：法人向けのサービスなら、入力した情報の保存の条件を確かめない

• エ：出力に出典らしい表記があれば、リンク先の確認を省く

正解：ア。入力の扱いと出力の確認を分けて整えます。イは自然な文章と正確さを混同しています。

問5　使わなくなったサブドメイン

外部のCDNサービスの利用を終えたが、そのサービスを指すCNAMEレコードが権威DNSサーバに残っている。最も適切な対応はどれか。

• ア：サービスの契約が終わったので、DNSの設定は放置してよい

• イ：CNAMEレコードを削除し、利用の終了時にDNSのレコードも消す手順を規程に加える

• ウ：Webサーバを停止すれば、サブドメインの悪用は起こらない

• エ：DNSの管理画面のパスワードを変えれば、問題は解消する

正解：イ。残ったレコードは、第三者にサービス側で同じ名前を登録され、サブドメインを乗っ取られる原因になります。エは管理画面の保護で、残ったレコードの問題は解決しません。

実務と国・自治体では

実務では、ひな形の文言を採用して終わりにしがちです。対象の業務ごとに、必要な手順、整備の担当、期限、確認者を一覧にし、整備の状況を責任者が確かめられるようにします。ドメイン名やクラウドのサービスのように部署が独自に契約できるものは、届出と台帳の登録を手続にして、利用の終了まで追います。

政府機関等の統一基準は、リスクの評価、対策基準の策定、運用規程と実施手順の整備をつなげ、整備の状況を責任者へ報告する構成になっています。総務省の自治体向けガイドラインは、基本方針と対策基準を情報セキュリティポリシーとし、実施手順は各業務に合わせて整備するものとしています。ポリシーの策定の後の周知・徹底と、運用・見直しも求めています。資料の位置付けは支援士解説1の1で整理しています。

まとめ

• 四つの文書をつなぐ。 基本方針は方向、対策基準は守るべき事項、実施手順は作業、記録は実施の証拠。

• 担当者が動ける文章にする。 主体・契機・期限・確認・記録・例外を決め、禁止には理由と代わりの手段を添える。

• 新しいITとドメイン名は、置き場所と権限で考える。 クラウド、仮想化、生成AIで情報の流れが変われば規程を見直す。ドメイン名・DNS・証明書は台帳で管理し、利用の終了時にレコードも消す。

• 見直して使い続ける。 定期の確認と変化の時の確認を組み合わせ、様式・設定・教育まで直して、判断する部署に必要な情報が届くようにする。

さらに深く学ぶなら

この記事の範囲を超えて、仕組みをもっと深く知りたい人向けの本です（試験対策の本ではありません）。

• ドメイン名とDNSの仕組み、リソースレコード、運用の注意点を、DNSの運用者の視点で詳しく学べる

関連記事

• 前提：情報セキュリティ方針は、何を守り、誰が決める？｜支援士解説1の1（方針の策定）

• あわせて読む：法律を知っていれば、コンプライアンスは守れる？｜支援士解説3の11（法令・契約と規程の改定）

• あわせて読む：バックアップがあれば業務は戻る？｜支援士解説3の3（事業継続とバックアップ）

• 次に読む：監査で何を確かめ、どう改善する？｜支援士解説1の5（情報セキュリティ監査）

2026年10月改訂：午後の出題例と記述の型を加え、ドメイン名・DNS・証明書の管理の節を新設し、事業継続の詳細は支援士解説3の3へ移して、確認問題を四択で作り直しました。