侵害対策を計画する
法則 1: 自分に身に何か悪いことが起こるなどと、それが起こるまでは誰も信じない。 - セキュリティ管理に関する 10 の不変の法則
多くの組織のディザスター リカバリー計画では、コンピューティング サービスの喪失につながる地域的な災害や障害からの回復に重点が置かれています。 しかし、侵害されたお客様と作業すると、意図的な侵害からの回復がディザスター リカバリー計画に含まれないことに気付くことがよくあります。 物理的な境界 (データセンターの破壊など) ではなく論理的な境界 (すべての Active Directory ドメインまたはすべてのサーバーの破壊など) を利用した知的財産の盗難や意図的な破壊につながる侵害のときは、それが特に当てはまります。 組織には、セキュリティ侵害が検出されたときに実行する初期アクティビティを定義したインシデント対応計画がある場合がありますが、多くの場合、これらの計画には、コンピューティング インフラストラクチャ全体に影響を与える侵害から回復するための手順が含まれません。
Active Directory は、ユーザー、サーバー、ワークステーション、アプリケーションに対して豊富な ID およびアクセス管理機能を提供するため、常に攻撃者のターゲットになります。 攻撃者が Active Directory のドメインまたはドメイン コントローラーへの高度な特権アクセスを獲得した場合、そのアクセスを利用して、Active Directory フォレスト全体にアクセスしたり、制御したり、さらには破棄したりすることができます。
このドキュメントでは、Windows と Active Directory に対する最も一般的な攻撃と、攻撃対象を減らすために実施できる対策について説明しますが、Active Directory の完全なセキュリティ侵害が発生した場合に回復するための唯一の確実な方法は、発生する前にセキュリティ侵害に備えておくことです。 このセクションでは、このドキュメントの前のセクションほど技術的な実装の詳細には注目せず、組織の重要なビジネスと IT 資産をセキュリティ保護して管理するための全体的で包括的なアプローチを作成するために使用できる高レベルの推奨事項について、より多く説明します。
インフラストラクチャが一度も攻撃されたことがないか、侵害の試みに抵抗したことがあるか、または攻撃に屈して完全に侵害されたことがあるかにかかわらず、将来的に何度も攻撃されるという避けられない現実に対して計画を立てる必要があります。 攻撃をなくすことはできませんが、重大な違反や大規模な侵害を防ぐことは実際に可能かもしれません。 すべての組織は、既存のリスク管理プログラムをよく評価し、防止、検出、抑制、回復にバランスよく投資することによって、全体的な脆弱性のレベルを下げるために必要な調整を行う必要があります。
インフラストラクチャやアプリケーションに依存するユーザーや企業にサービスを提供しながら、効果的な防御策を作成するには、環境内のセキュリティ侵害を防止、検出、抑制した後、侵害から回復するための、新しい手段を検討することが必要になる場合があります。 このドキュメントで説明するアプローチと推奨事項は、侵害された Active Directory のインストールの修復には役立たないこもしれませんが、次の侵害を防ぐのには役に立ちます。
Active Directory フォレストを回復するための推奨事項については、「AD フォレストの回復 - フォレストを復元する手順」を参照してください。 新しい環境が完全に侵害されるのを防ぐことができる可能性がありますが、そうでない場合でも、環境を回復して制御を取り戻すためのツールが用意されています。
アプローチの再考
法則 8: ネットワークを防御することの難しさは、その複雑さに直接比例する。 - セキュリティ管理に関する 10 の不変の法則
攻撃者がコンピューターに対する SYSTEM、管理者、ルート、または同等のアクセス権を取得した場合、オペレーティング システムに関係なく、システムを "クリーン" にしようとどれほど努力しても、そのコンピューターを信頼できると見なすことはもはやできないことは、広く認められています。 Active Directory の場合も違いはありません。 攻撃者が Active Directory のドメイン コントローラーへの特権アクセス権または高特権アカウントを取得した場合、攻撃者が行ったすべての変更の記録または既知の正常なバックアップを持っていない限り、ディレクトリを完全に信頼できる状態に復元することはできません。
メンバー サーバーまたはワークステーションが攻撃者によって侵害されて改ざんされた場合、そのコンピューターは信頼できなくなりますが、隣接している侵害されていないサーバーやワークステーションはまだ信頼できます。 1 台のコンピューターがセキュリティ侵害されても、すべてのコンピューターが侵害されたことを意味するわけではありません。
ただし、Active Directory ドメインでは、すべてのドメイン コントローラーが同じ AD DS データベースのレプリカをホストしています。 1 つのドメイン コントローラーが侵害され、攻撃者が AD DS データベースを変更すると、その変更はドメイン内の他のすべてのドメイン コントローラーにレプリケートされ、変更が行われたパーティションによっては、フォレストにもレプリケートされます。 フォレスト内のすべてのドメイン コントローラーを再インストールする場合でも、AD DS データベースが存在するホストを再インストールするだけです。 Active Directory に対する悪意のある変更は、何年も動いているドメイン コントローラーにレプリケートされるのと同じくらい簡単に、新しくインストールされるドメイン コントローラーにもレプリケートされます。
侵害された環境の評価では、最初の侵害 "イベント" と信じられていたものが、実際には、攻撃者が環境を侵害してから、数週間、数か月、または数年経ってからトリガーされたものであるとわかることがよくあります。 通常、攻撃者は、侵害が検出されるずっと前に高特権アカウントの資格情報を取得しており、それらのアカウントを利用して、ディレクトリ、ドメイン コントローラー、メンバー サーバー、ワークステーション、さらには接続されている非 Windows システムのセキュリティを侵害します。
これらの調査結果は、Verizon の 2012 年のデータ侵害調査レポートの複数の結果で一貫しており、次のように述べられています。
データ侵害の 98% は、外部のエージェントによるものであった
データ侵害の 85% は、検出されるまでに数週間以上かかった
インシデントの 92% は、サードパーティによって検出された
侵害の 97% は、簡単な制御または中程度の制御によって回避できた。
前に説明した程度の侵害は実質的に回復不可能であり、侵害されたすべてのシステムを "フラットにして再構築する" という標準的なアドバイスは、Active Directory が侵害されたり破壊されたりした場合は、単に適当ではないか、不可能な場合さえあります。 既知の良好な状態に復元しても、環境の最初の侵害を許した欠陥は取り除かれません。
組織はインフラストラクチャのすべてのファセットを防御する必要がありますが、攻撃者は望む目的を達成するのに十分な防御の欠陥を見つける必要があるだけです。 環境が比較的単純で初期状態に近く、それまでに適切に管理されている場合は、このドキュメントでこれまでに説明した推奨事項を実装するのは簡単なことです。
しかし、古く、大規模で、複雑な環境では、このドキュメントの推奨事項を実装できる可能性はずっと低くなるか、不可能になると考えられます。 問題が発生した後でインフラストラクチャをセキュリティ保護することは、新しく始めて、攻撃やセキュリティ侵害に対する耐性がある環境を構築するよりも、はるかに困難です。 ただし、前に説明したように、Active Directory フォレスト全体を再構築するのは簡単なことではありません。 このような理由から、より重点的に対象を絞ったアプローチで Active Directory フォレストをセキュリティ保護することをお勧めします。
"壊れている" すべてのものに焦点を当てて修正しようとするのではなく、ビジネスやインフラストラクチャにとって最も重要なものに基づいて優先順位を付けるアプローチを検討します。 古くなった不適切な構成のシステムやアプリケーションで満たされた環境を修復しようとするのではなく、ビジネスにとって最も重要なユーザー、システム、情報を安全に移植できる、新しく小規模でセキュリティ保護された環境を作成することを検討してください。
このセクションでは、主要なビジネス インフラストラクチャのための "生命ボート" または "安全なセル" として機能する初期状態の AD DS フォレストを作成する方法について説明します。 初期状態のフォレストは、新しくインストールされた Active Directory フォレストで、通常はサイズとスコープが制限され、最新のオペレーティング システム、アプリケーション、そして「Active Directory の攻撃を削減する」で説明されている原則を使用して構築されます。
新しく構築されたフォレストに推奨される構成設定を実装することにより、セキュリティ保護の設定と手法を使用して一から構築された AD DS のインストールを作成でき、レガシ システムやアプリケーションのサポートに付随する課題を減らすことができます。 初期状態の AD DS のインストールの設計と実装に関する詳細な手順については、このドキュメントでは説明しませんが、いくつかの一般的な原則とガイドラインに従って、最も重要な資産を格納できる "安全なセル" を作成する必要があります。 これらに関するガイドラインは次のとおりです。
重要な資産を分離してセキュリティで保護するための原則を明確にする。
制限されたリスクベースの移行プランを定義する。
必要に応じて "非移行型" の移行を利用する。
"創造的破壊" を実装する。
レガシ システムとレガシ アプリケーションを分離する。
エンド ユーザー向けのセキュリティを簡素化する。
重要な資産を分離してセキュリティで保護するための原則を明確にする
重要な資産を格納するために作成する初期状態の環境の特性は、大きく異なる場合があります。 たとえば、VIP ユーザーと、それらのユーザーだけがアクセスできる機密データのみを移行する初期状態のフォレストを作成することを選択できます。 VIP ユーザー以外も移行するように初期状態のフォレストを作成するけれども、管理フォレストとして実装し、「Active Directory の攻撃を削減する」で説明されている原則を実装して、初期状態のフォレストからレガシ フォレストを管理するために使用できるセキュリティで保護された管理アカウントとホストを作成することもできます。 VIP アカウント、特権アカウント、およびセキュリティを強化する必要があるシステム (Active Directory 証明書サービス (AD CS) を実行しているサーバーなど) を格納し、セキュリティが弱いフォレストからそれらを分離することだけを目的とする、"専用" フォレストを実装する場合もあります。 最後に、すべての新規ユーザー、システム、アプリケーション、データのための事実上の場所になる初期状態のフォレストを実装し、最終的には漸減によりレガシ フォレストの使用を停止することもあります。
初期状態のフォレストが、少数のユーザーとシステムを格納するのか、またはより積極的な移行のための基礎を形成するのかに関係なく、計画では次の原則に従う必要があります。
レガシ フォレストが侵害されたと仮定します。
初期状態の環境がレガシ フォレストを信頼しないように構成してください。ただし、初期状態のフォレストがレガシ環境を信頼するように構成することはできます。
アカウントのグループ メンバーシップ、SID 履歴、またはその他の属性が悪意をもって変更されている可能性がある場合は、ユーザー アカウントまたはグループをレガシ フォレストから初期状態の環境に移行しないでください。 代わりに、"非移行型" アプローチを使用して初期状態のフォレストにデータを設定します。 (非移行型アプローチについては、このセクションの後半で説明します。)
レガシ フォレストから初期状態のフォレストにコンピューターを移行しないでください。 初期状態のフォレストに新しくインストールしたサーバーを実装し、新しくインストールしたサーバーにアプリケーションをインストールし、新しくインストールしたシステムにアプリケーション データを移行します。 ファイル サーバーの場合は、新しくインストールしたサーバーにデータをコピーし、新しいフォレストのユーザーとグループを使用して ACL を設定してから、同様の方法でプリント サーバーを作成します。
初期状態のフォレストへのレガシ オペレーティング システムまたはアプリケーションのインストールは許可しないでください。 アプリケーションを更新して新たにインストールできない場合は、レガシ フォレストに残しておき、創造的破壊を行ってアプリケーションの機能を置き換えることを検討します。
制限されたリスクベースの移行プランを定義する
制限されたリスクベースの移行プランの作成とは、簡単に言えば、初期状態のフォレストに移行するユーザー、アプリケーション、データを決定するときに、ユーザーまたはシステムの 1 つがセキュリティ侵害された場合に組織がさらされるリスクの程度に基づいて、移行ターゲットを明確化する必要があることを意味します。 攻撃者のターゲットになる可能性が最も高いアカウントを持つ VIP ユーザーを、初期状態のフォレストに入れる必要があります。 重要なビジネス機能を提供するアプリケーションを、初期状態のフォレスト内に新しく構築されたサーバーにインストールする必要があり、機密性の高いデータを初期状態のフォレスト内のセキュリティ保護されたサーバーに移動する必要があります。
Active Directory 環境内にある、ビジネスにとって最も重要なユーザー、システム、アプリケーション、データをまだ明確に把握していない場合は、部署と協力してそれらを明らかにします。 重要なアプリケーションが実行されていたり重要なデータが格納されているサーバーを特定する必要があるので、ビジネスの運用に必要なアプリケーションを特定します。 組織が引き続き機能するために必要なユーザーとリソースを特定することにより、作業を集中する、自然に優先順位付けされた資産のコレクションを作成します。
"非移行型" の移行の利用
環境が侵害されたことがわかっているのか、侵害された可能性があるのか、またはレガシのデータとオブジェクトをレガシ Active Directory のインストールから新しいものに移行したくないだけなのかにかかわらず、技術的にはオブジェクトを "移行" しない移行アプローチを検討します。
ユーザー アカウント
あるフォレストから別のフォレストへの従来の Active Directory の移行では、ユーザーオブジェクトの SIDHistory (SID 履歴) 属性を使用して、ユーザーの SID と、レガシ フォレストでユーザーがメンバーであったグループの SID を格納します。 新しいフォレストに移行されたユーザー アカウントが、レガシ フォレスト内のリソースにアクセスする場合は、SID 履歴の SID を使用して、アカウント移行前にユーザーがアクセス権を持っていたリソースへのアクセスを許可するアクセス トークンが作成されます。
ただし、ユーザーのアクセス トークンに現在と過去の SID を設定するとトークンが肥大化する可能性があるため、SID 履歴を保持することは一部の環境では問題があります。 トークンの肥大化とは、ユーザーのアクセス トークンに格納する必要がある SID の数が、トークンで使用可能な領域の量に達するか、それを超えてしまう問題です。
トークンのサイズは限られた範囲で増やすことができますが、トークンの肥大化の最終的な解決策は、グループ メンバーシップの合理化、SID 履歴の削除、またはその両方の組み合わせによって、ユーザー アカウントに関連付けられている SID の数を減らすことです。 トークンの肥大化について詳しくは、「MaxTokenSize と Kerberos トークンの肥大化」をご覧ください。
SID 履歴を使用してレガシ環境 (特に、グループ メンバーシップと SID 履歴が侵害されている可能性がある環境) からユーザーを移行するのではなく、メタディレクトリ アプリケーションを利用して、SID 履歴を新しいフォレストに移動せずに、ユーザーを "移行する" ことを検討します。 新しいフォレストにユーザー アカウントが作成されたら、メタディレクトリ アプリケーションを使って、そのアカウントをレガシ フォレスト内の対応するアカウントにマップできます。
新しいユーザー アカウントが従来のフォレスト内のリソースにアクセスできるようにするには、メタディレクトリ ツールを使用して、ユーザーのレガシ アカウントがアクセスを許可されていたリソース グループを特定し、そのグループにユーザーの新しいアカウントを追加します。 レガシ フォレストでのグループ戦略によっては、新しいアカウントをリソース グループに追加できるようにするために、リソース アクセス用のドメイン ローカル グループを作成するか、既存のグループをドメイン ローカル グループに変換することが必要になる場合があります。 最初に最も重要なアプリケーションとデータに注目し、それらを (SID 履歴を使って、または使わずに) 新しい環境に移行することにより、レガシ環境で費やされる作業量を制限できます。
サーバーとワークステーション
異なる Active Directory フォレスト間の従来の移行では、多くの場合、コンピューターの移行は、ユーザー、グループ、アプリケーションの移行に比べて比較的簡単です。 コンピューターの役割によっては、古いドメインへの参加を解除して新しいドメインに参加するだけで、簡単に新しいフォレストに移行できます。 ただし、コンピューター アカウントをそのまま初期状態のフォレストに移行するのでは、新しい環境を作成する目的が損なわれます。 新しいフォレストに (侵害されている、正しく構成されていない、または古くなっている可能性がある) コンピューター アカウントを移行するのではなく、新しい環境にサーバーとワークステーションを新しくインストールする必要があります。 レガシ フォレスト内のシステムから初期状態のフォレスト内のシステムにデータを移行することはできますが、データを格納しているシステムを移行することはできません。
アプリケーション
アプリケーションは、異なるフォレスト間の移行において最も大きな課題になる場合がありますが、"非移行型" の移行において、適用する必要がある最も基本的な原則の 1 つは、初期状態のフォレスト内のアプリケーションは、最新で、サポートされていて、新しくインストールされている必要がある、というものです。 可能であれば、古いフォレスト内のアプリケーション インスタンスからデータを移行できます。 初期状態のフォレストにアプリケーションを "再作成" できない場合は、次のセクションで説明するように、創造的破壊やレガシ アプリケーションの分離などのアプローチを検討する必要があります。
"創造的破壊" を実装する
創造的破壊とは、それまでの秩序の破壊によって生み出される経済発展を表す経済用語です。 最近は、この用語が情報技術に適用されるようになっています。 これは通常、アップグレードするのではなく、完全に新しいものに置き換えることによって、古いインフラストラクチャを廃絶するメカニズムを指します。 2011 年に CIO や上級 IT 役員を対象に行われた Gartner Symposium ITXPO では、コスト削減と効率性向上のための主要なテーマの 1 つとして、創造的破壊が示されました。 セキュリティの改善は、そのプロセスの自然な結果として実現できます。
たとえば、組織は、実行する機能は似ていても、近代化とベンダー サポートのレベルが同じではない異なるアプリケーションを使用する、複数の部署で構成される場合があります。 これまでは、IT 部門が各部署のアプリケーションを個別に管理する責任を負っている場合があり、統合作業は、最適な機能を提供するアプリケーションを明らかにした後、他のアプリケーションからそのアプリケーションにデータを移行する作業で構成されました。
創造的破壊では、古いアプリケーションや冗長なアプリケーションを維持するのではなく、まったく新しいアプリケーションを実装して古いものを置き換え、データを新しいアプリケーションに移行し、古いアプリケーションとそれが実行されていたシステムの使用を停止します。 場合によっては、独自のインフラストラクチャに新しいアプリケーションを展開することで、レガシ アプリケーションの創造的破壊を実装できますが、可能な限り、代わりにクラウドベースのソリューションへのアプリケーションの移植を検討する必要があります。
クラウドベースのアプリケーションを展開して社内のレガシ アプリケーションを置き換えることで、メンテナンス作業とコストを削減できるだけでなく、攻撃者が利用する脆弱性を持つレガシ システムやアプリケーションをなくすことで、組織への攻撃が減ります。 このアプローチにより、組織は、必要な機能をより迅速に取得しながら、同時にインフラストラクチャ内のレガシ ターゲットを排除できます。 創造的破壊の原則は、すべての IT 資産に適用されるわけではありませんが、多くの場合、レガシ システムとアプリケーションを排除しながら、同時に堅牢でセキュリティ保護されたクラウドベースのアプリケーションをデプロイするための、実行可能なオプションが提供されます。
レガシ システムとレガシ アプリケーションを分離する
ビジネスに不可欠なユーザーとシステムを初期状態の安全な環境に移行することの自然な結果として、レガシ フォレストには価値の低い情報とシステムが含まれるようになります。 安全性の低い環境に残っているレガシ システムとアプリケーションは、侵害のリスクが高くなる可能性がありますが、セキュリティ侵害の重大度の低下も表します。 重要なビジネス資産のホームを変えて最新化することで、従来の設定やプロトコルに対応する必要はなくなり、効果的な管理と監視の展開に集中できます。
これらのシステムを強制的にレガシ設定が実装されたドメインから削除することで、その後、現在のオペレーティング システムとアプリケーションのみをサポートするように構成して、ドメインのセキュリティを強化できます。 ただし、可能な限り、レガシ システムとアプリケーションを使用停止にすることをお勧めします。 従来の使用者の小規模なセグメントについて使用を停止することが単に実現できない場合は、別のドメイン (またはフォレスト) に分離することで、残りのレガシ インストールで段階的な改善を実行できます。
エンド ユーザー向けのセキュリティを簡素化する
ほとんどの組織では、組織内での役割の性質上、最も機密性の高い情報にアクセスできるユーザーは、多くの場合、複雑なアクセスの制限と制御の学習に当てられる時間が最も少ないユーザーでもあります。 組織内のすべてのユーザーのために包括的なセキュリティ教育プログラムを用意する必要がありますが、透過的な制御を実装し、ユーザーが従う原則を簡略化することで、セキュリティを可能な限り使いやすいものにすることにも目を向ける必要があります。
たとえば、役員や他の VIP は、機密データやシステムにアクセスするにはセキュリティで保護されたワークステーションを使用する必要があり、機密性の低いデータにアクセスする場合は他のデバイスを使用できるという、ポリシーを定義することができます。 これはユーザーが簡単に覚えられる原則ですが、アプローチの適用に役立つ多数のバックエンド コントロールを実装できます。
認証メカニズムの保証を使用すると、ユーザーがスマート カードを使用してセキュリティで保護されたシステムにログオンしている場合にのみ、機密データにアクセスすることを許可することができます。また、IPsec とユーザー権利の制限を使用して、ユーザーが機密データ リポジトリに接続できるシステムを制御できます。 ダイナミック アクセス制御を実装すると、試みられたアクセスの特性に基づいてデータへのアクセスを制限し、ビジネス ルールを技術的な制御に変換できます。
ユーザーから見ると、セキュリティで保護されたシステムから機密データにアクセスすると "成功するだけ" であり、セキュリティで保護されていないシステムから試みると "失敗するだけ" です。一方、環境の監視と管理の観点からは、ユーザーが機密データやシステムにアクセスする方法で識別可能なパターンを作成しているのであり、異常なアクセス試行を簡単に検出できます。
長く複雑なパスワードをユーザーが毛嫌いすることによる、特に VIP ユーザーにおけるパスワード ポリシーが不十分な環境では、認証に対する代替アプローチを検討してください。 代替アプローチには、スマートカード (さまざまなフォーム ファクターで、認証強化のための追加機能を装備）、フィンガースワイプ リーダーのような生体認証、あるいはユーザーのコンピューターに搭載されたトラステッド プラットフォーム モジュール (TPM) チップによってセキュリティ保護された認証データなどがあります。 コンピューターが既に侵害されている場合、多要素認証では資格情報盗難攻撃を防ぐことはできません。 ただし、ユーザーに使いやすい認証制御を提供することで、従来のユーザー名とパスワード制御が扱いにくいユーザーのアカウントに、より堅牢なパスワードを割り当てることができます。