intcube の CTO、David Fuhr 氏が、公共機関向けのセキュリティ・コホートについて語ります。この取り組みでは、27の自治体が12週間にわたり、Windows Server と Active Directory の堅牢化に共同で取り組みました。Help Net Security のインタビューでは、毎週のセッションや宿題、開始時と終了時の測定といったコホートの進め方を取り上げています。
Fuhr 氏は、SMB署名、LDAP署名、Kerberosの堅牢化など、システム障害を引き起こしかねない設定にグループがどう対処したかを説明します。ラボでの変更テストや、ロールバック計画の進め方にも触れました。さらに、導入後に設定を誰が管理するのか、グループを2つに分けた理由についても語っています。
当初は10〜15の自治体を想定していましたが、実際には27が参加しました。この数字から、アンケートでは見えない地方自治体のActive Directoryセキュリティの実態について、何が分かりますか。
まず分かったのは、問題は「意識」ではないということです。参加した自治体は、サーバーやActive Directoryのセキュリティに取り組む必要があると理解していました。別のアンケートを実施しても、問題の大きさが分かるだけです。具体的に何から始めればよいのかは、見えてきません。
そこで「10〜15の組織が同時に、効率よく一緒に取り組める仕組みがあります」と提案したところ、この方法が理にかなっていることを、それほど説得しなくても理解してもらえました。ただ、自治体にとっては不慣れな形式だったため、進め方や運営方法に慣れるまで少し時間がかかりました。最終的には、27の自治体IT部門が参加を希望したため、午前と午後の2グループに分ける必要がありました。
根本原因が技術的なものでないなら、何が原因なのでしょうか。管理者が1〜2人の組織で、既知のADの弱点が何年も残るのはなぜですか。
技術的には、すべて解決可能です。難しくはありますが、解決はできます。Active Directoryは古い技術で、多くの負債を抱えています。技術的負債、組織的負債、プロセス上の負債です。特に、何十年もMicrosoft製品を使い続けてきた組織ではそうです。
制約になっているのはリソースだと考える人もいるでしょう。ある意味ではその通りですが、問題はお金ではありません。ツールやライセンスに予算を増やしても、1〜2人の管理者が多くのテーマや業務を抱えている状況は変わりません。本当に足りないのはモチベーションです。やる気がないわけではありません。皆さん、さまざまな穴をふさごうと懸命に努力しています。欠けているのは「この課題を本当に解決できる」という手応えです。それがあるからこそ、取り組む意義が生まれます。この手応えが全員を巻き込み、最終的に熱気を生み出しました。
出発点は州全体のセキュリティ監査で、多くの自治体が最大150ページに及ぶ報告書を受け取りました。そこから、2人のチームが実行できる計画へ、どう落とし込むのですか。
優れた報告書であっても、150ページを実際に読む人はいませんし、ましてそれに基づいて行動する人はなおさらいません。これはインセンティブの設計が悪いゲームのようなものです。報告書を、重要な5〜8ページに絞り込むことはできます。それでも、取り組むための時間とエネルギーは必要です。エネルギーはモチベーション以上に重要です。だからこそ、スポーツや、山登りで互いをロープでつなぐパーティーのように、仕組みと仲間が助けになります。皆で一緒に取り組むのです。
コホートは実際にどう機能するのですか。なぜ従来の1対1の支援よりも、堅牢化が進むのでしょうか。
コホートの強みは、同じ課題を抱える組織（今回は自治体）をグループにできることです。課題が似ていたり、進捗段階が近かったりします。そうした組織向けに、あらかじめ決めた週数で進めるプログラムを設計します。課題によって、12週間、16週間、24週間などになります。
プログラムにはリズムがあります。たとえば、毎週水曜の午前または午後に2時間のセッションを行い、加えてプラットフォーム上で非同期の作業、いわば宿題に取り組みます。この期間中、課題解決の各段階を全員で順にたどります。知識の移転も数多く行います。コンサルティングと同様に、私たち専門家が必要な知識、ツール、テンプレートを提供します。ただし実際の作業は、各組織が自分の課題を並行して解決します。互いに、そしてチームや過去のコホートから学び合います。
開始時と終了時に測定を行うため、グループは常に現在地と、共通の目標までの残りを把握できます。これが勢いを生みます。「今は9週目で、あと3週間。前回のコホートはこの時点でここまで進んでいた。もう少しで届く」といった具合です。本気で駆け抜ければ、目標の100％、あるいは120％まで達成できます。これが意欲につながります。
SMB署名、LDAP署名、Kerberosの堅牢化は、障害を引き起こしやすいことで知られています。グループはそのリスクにどう対処し、例外を認める基準をどう判断したのですか。
コホートにはいくつかのフェーズがありました。最初のフェーズでは、理解を深めるだけでなく、基本的なロギングと監査を設定しました。これにより、各組織が自分のインフラで何が起きているのかを確認できます。どのバージョンのSMBが使われているか、LDAP署名が有効かどうかといった点です。全員の環境で設定が整い、動作するようになってから別のテーマに進み、数週間後に監査ログに戻って結果を確認しました。こうして、先に進んでよいと判断できました。
一部の組織には、個別に例外対応をする必要がありました。それは常に想定していることです。15組織のコホートなら、2〜3組織とは1対1で向き合い、グループの他のメンバーに遅れないために必要なことを一緒に検討します。何がうまくいかない可能性があるのかも、率直に話し合いました。残存リスクを受け入れるかどうかの判断はこちらでは行わず、各組織に委ねました。それでも、自由に意見交換できる場があったため、最終的には全員が自信を持てました。各ステップを実施した大多数の組織は、良い経験をしています。
27の本番環境に影響が及ぶ前に、変更をどうテストしたのですか。ロールバック計画はどのようなものでしたか。
すべての変更を、自前のテスト環境で検証しました。ごく単純な自治体のインフラを模した小さなラボを用意し、標準的なケースだけでなく、起こりうる問題もすべて実演しました。ロールバック計画は、各組織が個別に立てました。ローカルのインフラによって大きく異なるためです。参加者は皆、その点を熟知しています。つまり私たちが行ったのはリスク管理で、各組織がそれぞれ自分で実施しました。私たちは手法と議論の場を提供し、グループ内で話し合いました。
構成のドリフトは、堅牢化プロジェクトが静かに頓挫する原因になりがちです。IT担当者が2人の自治体で、6か月後にこれらの設定を管理するのは誰ですか。
答えは2つあります。1つ目は、コホートが副産物としてコミュニティを生むことです。今回の場合は12週間でコホートが終わった後も、参加者は連絡を取り合っています。プラットフォームや意見交換のチャンネルは今も残っており、皆さんそれを使って課題に取り組んでいます。以前ほど集中的ではなく、毎週でもありませんが、コミュニティは生きています。支援なしで永続するとまでは言いませんが、活動の土台にはなります。
2つ目は、1回のコホートで、1つの自治体のITセキュリティ全体はおろか、ADセキュリティの課題すべてを解決することもできないという点です。より大きな視点では、プログラムが必要です。組織が定期的に取り組む一連のコホートです。大きなリズムの中に小さなリズムがある、ピラミッドのような構造です。それぞれのコホートが次の段階に進む助けとなり、次に穴のあるテーマへと移っていきます。こうして各組織は自分のペースで前進し、新たな成熟度に到達します。
27組織を2グループに分けました。コホートモデルの限界はどこにありますか。
私は限界とは考えていません。コホートの安全な場には、他の参加者の状況が全員に見えるグループが必要です。全員が全員と話すという意味ではなく、フルメッシュである必要はありません。ただし、互いの話に耳を傾けることが大切です。学校のクラスを考えてみてください。25〜35人は明らかに多すぎます。そのため、1コホートあたり10〜15組織を目標にしています。
初の自治体向けITセキュリティ・コホートに27件の応募があったため、2つのグループに分けました。結果的に、これは良い方向に働きました。2つのグループは互いに学び合い、共通の場を共有できます。午前に試したことを、午後に少し調整して実施することもできます。単一コホートのモデルを強化する形になりました。
翻訳元: https://www.helpnetsecurity.com/2026/10/16/david-fuhr-intcube-active-directory-security/
