セキュリティ入門

  • [アーティクル]

セキュリティ要素構成アーキテクチャ

Markus Vilcinskas

目次

マイクロソフト ソリューション フレームワーク

メモ : このホワイトペーパーは、ベスト プラクティス シリーズの一部です。企業セキュリティのベスト プラクティスには、このシリーズを構成するホワイトペーパー一覧が掲載されています。

トピック

ドキュメントの目的
はじめに
セキュリティ アーキテクチャの必要性
セキュリティ アーキテクチャ要素の定義
セキュリティ ニーズ
構成要素の構造

ドキュメントの目的

組織の中では、コンピュータ同士を接続して業務上重要なデータを格納、処理、共有して使うことが増えるに従って、ネットワークの安全性を高める必要性が大きくなってきました。企業グループでは、機密データに複数の場所からアクセスするやり方にますます依存するようになっており、これは組織内だけでなく外部からも同様です。

こうした状況では、データのセキュリティを高めるための技術を注意深く管理する必要があります。コンピュータ業界は、格納と通信プロセスに関する特定の側面の安全性を高める技術を多数開発しています。これらの技術は、互いに組み合わせて利用するための計画がないと、うまく働きません。

このドキュメントには、セキュリティ関連の問題についての情報と、セキュリティを企画、実装する際に考慮すべきリスクと対策の概要が示されています。このドキュメントでは、SEBA (Security Entity Building Block Architecture) も紹介しています。これはあらゆる環境でセキュリティ計画の作成、導入を成功させる基盤として利用可能です。

質問とフィードバックを歓迎いたします。 問い合わせの送信先 : markvi@microsoft.com (英語のみ)

ページのトップへ

はじめに

セキュリティの目的

セキュリティの目的には、データと IT (Information Technology) ネットワークを多種多様な脅威から守ることがあります。企業でこれを実現しようとすると難問に直面します。技術を最大限に活用するには、企業の内外にいるユーザーに対して、企業ネットワークへのアクセスと、このネットワークに含まれるリソースへのアクセスを提供する必要があるからです。従って、企業はアクセス権限の種類を制御して、それぞれのユーザーに対して異なるリソースにアクセスする権限を与える必要があります。

まず最初に、特定システム リソースが、データやプログラムが格納されている個々のコンピュータのレベルから、ネットワーク全体に至るまで、そのリソースの利用権限を持つユーザーに開放されていて、かつ、他の人からは利用できないということを保証する必要があります。 オペレーティング システムのアクセス管理機能を使えば、このような保護機能を提供できます。オペレーティング システムでは、ファイルその他のリソースへのアクセスをしっかりと管理するためにセキュリティのしくみを活用しています。このしくみには、ユーザーとユーザーのアクセス権限を識別する個人のユーザー プロファイル、および異なるリソース環境間で差別化を行うしくみが含まれます。このしくみにより、データを操作したり盗んだりするために、アクセスを試みる侵入者のような脅威から守られます。

注 このペーパー中で何度も引き合いに出すオペレーティング システムとは Microsoft Windows 2000 と Microsoft Windows NT システムを指します。Microsoft Windows 9X オペレーティング システムには、高度なセキュリティのしくみはありません。

ビジネス上、社内ネットワークの外にいる顧客等のユーザーから特定のリソースを利用できるようにする必要もあります。理想を言えば、このようなユーザーは、いかなる場合でも最高の性能でリソースにアクセスできる必要があります－－このようなサービスでは、信頼性の高いアクセスを提供することが重要な価値となります。サービスの例としては、オンライン バンキングとオンライン ショッピングがあります。この場合には外部ユーザーが企業ネットワークを利用し、企業データにアクセスして処理を行います。ただし、リソースを利用できることが、各種攻撃の対象となり得ます。たとえば、DoS 攻撃 (Denial of Service) はよく知られているタイプの攻撃です ‐ この攻撃はデータ アクセスを困難にするか不可能にすることを目的としており、企業のビジネス機会の損失につながります。

セキュリティのしくみは、危害を加える意図を持ってシステムに攻撃を加える人からデータを保護するだけでなく、誤ってあるいは知らないうちに IT リソースに損害を与えることを防ぐことで、組織を守りユーザーを保護します。これはセキュリティ デバイスとセキュリティ手順、セキュリティ ポリシーを組み合わせて利用することで達成できます。

セキュリティ レベルとコスト

日常生活でも IT 環境でも同じですが、完全なセキュリティを達成することは神話に近いものがあります。では、どの程度のセキュリティが必要なのでしょうか。企業にとって適切と考えられるセキュリティ レベルは、守るべき情報の価値、その情報が受ける脅威、および企業が受け入れるリスクの関数となります。

すると次の問いは、コストはどれくらいかかるか、ということになります。コストには、ハードウェア、ソフトウェア、ネットワーク、メンテナンス、および教育コストだけでなく、あまりはっきりしない処理コストも加わります。すべてのセキュリティ ベースのサービスには、ある程度の処理コストがかかります。この処理コストの影響は、アクセス タイムの劣化またはその他の望ましくない兆候として現れます。

したがって、管理者は利用可能なすべてのセキュリティのしくみを理解するだけでなく、不要な出費を避けるための特定のシナリオに必要な、セキュリティ レベルを判断することが重要になります。意志決定者は、保護するリソースごとに、セキュリティ機能の費用について、さらに投資する価値があるかどうかを決定する必要があります。実装するセキュリティ対策の決定には、性能 (生産性)、データ保護、および必要なコストの最適な妥協点を見つけることが必要になります。良いソリューションでは :

適切な人だけが、最小のコストと最大の性能で正しい情報にいかなる時にもアクセスできます。

セキュリティの実装

コンピュータ セキュリティの対象になるのは、ローカル ワークステーションまたはサーバーからイントラネット、およびその先というように企業全体から見えるものすべてなので、"特効薬" ソフトウェア製品によるソリューションを実装するだけで、あるいはファイアウォールをインストールでだけで解決するものではありません。コンピュータ セキュリティは、環境の各レベルでセキュリティ関係のタスクを実行する信頼度の高いしくみを利用して実装する必要があります。実装する際には、このような各レベルでセキュリティ手順とポリシーを適用することも必要となります。

ページのトップへ

セキュリティ アーキテクチャの必要性

前セクションでは、IT セキュリティの目標を一般的に定義しました。次のステップでは、ネットワーク環境内で保護すべきリソースの場所を決定します。

セキュリティ問題の複雑さ

セキュリティは、情報システムを計画、管理する上で重要な役割を果たします。コンピュータ セキュリティは、データが発生するコンピュータだけでなく、そのデータが通過する各種ネットワークの通過点も関係する非常に複雑で多面的な問題です。このため、セキュリティが破られる可能性がある各通過点を見つけだして保護することが重要です。セキュリティを実装しても、一番弱いリンクの安全性を越えることはできません。

データ フローの分析

脆弱な点を見つけ出すためには、ネットワーク内のデータ フローを分析する必要があります。この視点からは、基本的なシナリオが 2 つあります。

  1. コンピュータ内に格納されているデータ。 ローカルなコンピュータ内の格納データについては、主にオペレーティング システムが保護すべきタスクに必要なサービスを提供してくれます。このようなサービスを利用するにあたっては、サービスが適切に設定されている必要があります。

  2. 通信ポイントを通過していくデータ。 複数の場所を通過するデータは、様々な方法で保護する必要があり、暗号化するケースが多くなります。一般に、このデータは次の 2 つの形をとります。システムに入ってくるネットワーク パケット形式のデータと、システムから出て行くデータです。

入力データの保護には、データ自体の保護と、ネットワークに入ってくるデータがもたらす脅威からシステムを保護することの両方があります。保護の方法には、システム チェックを行って、権限がある送信者からのデータであること、許可されたタスクだけを実行することを確認する方法があります。

コンピュータを出ていくデータの保護には、データを変更せずデータの送信時と正確に同じ形であて先に到達することを保証することが含まれます。データのコンテンツは言うまでもなく、セッションとデータのタイプも第三者から読めないようにする必要があります－－すなわち、プライバシを保証する必要があります。

ネットワーク接続シナリオ

最近の企業ネットワークでは、それぞれのコンピュータに、データをやり取りする方法を何通りか提供するのが普通です。個々のコンピュータにはモデムを設置して、利用できるいろいろなシナリオに応じた接続を設定することができます。さらに、ほとんどのコンピュータはローカルな (内部) ネットワークに接続されていて、そこから枝分かれして多くの目的地に到達できます。

典型的なネットワーク シナリオの例 :

  • プライベート ネットワークを他社と共有する企業ネットワーク。

  • ISP に存在する Web サーバーを利用する企業ネットワーク。ここにはダイヤルアップまたは常時接続経由でアクセス可能です。

  • ダイヤルアップ接続を利用する企業ネットワーク。

  • インターネットに常に接続している企業ネットワーク。

次の図は、複数のデータ トランスポート接続がある典型的なネットワークを示しています。

図 1: 典型的な企業ネットワーク

拡大表示する

このシナリオの複雑さと、それによってセキュリティ侵害の機会が多くなることを考えると、セキュリティの実装は段階を追って進めるべきです。データが収容されている主要なローカル リソースから始めて、次に中継ポイントに実装し、最終的に "その他世界中すべて" への常時接続にも実装していくことをお勧めします。

セキュリティ実装を段階を追って進めていくには、適切な分析と導入アーキテクチャが必要となります。

ページのトップへ

セキュリティ アーキテクチャ要素の定義

組織がセキュリティ ニーズを分析し、セキュリティ対策を導入できるアーキテクチャを組み立てるには、ネットワーク構造全体を考察して、その構造を個別のセキュリティ要素に分ける必要があります。このような要素は物理的かつ概念的なものであるべきです。そうすると、各要素についてセキュリティ漏洩を判定し、セキュリティを実装することが可能になります。このようなモデルで問題となるのは、要素またはゾーンの決定です。ここで提示するアーキテクチャ モデルでは各要素を説明し、セキュリティ リスク分析の実施時に、この要素がシステム内で果たす役割を関連付けます。

エンド システム要素

ネットワーク内の基本的なセキュリティ要素であるエンド システム要素は、オペレーティング システムを搭載しているコンピュータです。現在のネットワークでは、コンピュータには決まった役割があります。ワークステーションとサーバーの差別化は、よく使われる基本的なカテゴリ分けです。ただし、アプリケーション サーバーやコントローラの役割のように、サーバーにも異なる役割があります。

結果として、コンピュータの役割と扱うデータの種類に基づいて、セキュリティの視点からコンピュータを高、中、低の異なるセキュリティ レベルに分類する必要があります。このシステムは機密資料を扱う政府職員に割り当てられるセキュリティ ランクと同じものと考えられます。

この分類の詳細度または詳細レベルは、特定環境内でのセキュリティの必要性によります。この分類は、注意深く検討してドキュメントに残し、あまり明白でない潜在的な弱点を見つけだすために割り当てたレベルの正確性を保証する必要があります。たとえば、普通に考えるとサーバーの方が重要に思えますが、サーバーとしてのセキュリティ リスクという意味では、通常はワークステーションの方を高いセキュリティ レベルにすることをお勧めします。人は機密データを自分のローカル マシンにダウンロードして、オフラインで利用できるようにする傾向があります。もしワークステーションがラップトップで、このラップトップが盗難に遭うことを想定するなら、データを適切な方法で保護する高リスクのエンド システムとしてラップトップを分類しておくと、データの安全性が高まります。

次のステップでは、セキュリティ リスクを分析するエンド システム要素の項目を決定します。 これに含まれるものを示します。

  • ローカルなアカウント ポリシー

  • ローカル ポリシーとイベント ロギング

  • 制限付きグループ

  • レジストリのセキュリティ

  • ファイル システム セキュリティ

  • システム サービス セキュリティ

リスクを判定した後、この要素の最後のステップは対策の導入です。オブジェクト導入の実施は 2 ステップで行うのが通常の戦略です。

  1. 最初のステップでは、使用しているシステムのタイプとグレードとは無関係に、必要な設定変更をすべて行います。一例として、オペレーティング システムのコンポーネントが格納されているフォルダのファイル システムのアクセス許可があります。このような設定は無人セットアップ プロセスで行えます。

  2. 2 番目のステップでは、システム グループの個々の必要性に応じて構成設定を行います。 このような設定は通常、システム ポリシーを使って実装します。

再度確認しておくと、エンド システムとはオペレーティング システムを有するコンピュータ ハードウェア機器のことです。第 1 のセキュリティ目標は、永久保存データおよびオペレーティング システム関連のサービスを、常に保護することです。この要素内で考える際、装置上にインストールしている通信装置 (ネットワーク アダプタ、モデム等) は除外できます。これらはローカルな通信システム要素を構成するものです。

ローカル通信システム要素

コンピュータ間でデータがやり取りされるようになると、セキュリティ関連問題は次の基本的なステップに移ります。これがいわゆるネットワーク機能です。ネットワークの目標は、ローカルなリソースをリモート コンピュータから共有することです。管理者は、ローカル リソースのどの部分がリモート システムからアクセス可能となるべきかを指定します。セキュリティ サービスの目標は、権限のあるユーザーにのみこれらのリソースが利用可能となるように保証することです。

リモート リソースのアクセスには、別のテクノロジを利用できます。主な装置としては、ネットワーク アダプタとダイヤルアップ装置があり、ワークステーションに接続されているモデムから企業の NAS (Network Access Server) にまでわたっています。

ネットワーク ノード (ネットワーク パケット) 間を通過するデータに関する通常のリスクとしては、このパケットが侵入者により傍受され、読み出されて、最悪の場合には改ざんされるということがあります。ネットワーク パケットの内容が指定された受取人以外の人に読まれるというリスクは、インターネットのように信頼できないネットワークを利用する機会が増加しているため、劇的に増加しています。

転送中、データはオペレーティング システムのサービスでは直接は保護できません。ただし、2 ノード間にトンネルを作り、情報を暗号化する別の技術 (プロトコル) があります。これらの技術にはすべて個々の制約があり、適切なテクノロジやテクノロジの組合せは、十分に検討して決める必要があります。

セキュリティの視点からは、情報交換に関して次の 2 つの大きな問題があります。

  1. コンピュータを出ていくデータは、目的地に着くまでの間に読まれたり変更されたりせずに相手先に到達する必要があります。

  2. コンピュータに到達して入力されるパケットは、必ず、権限のあるユーザーから送られなければならず、パケットの目的は承認されたタスクを遂行するものでなければなりません。

管理機関要素

企業ベースのネットワークでは、エンド システムとローカル通信システムを個別に管理することはできません。このようなネットワークのシステムは全世界に配置されており、管理タスクには集中型のセキュリティ管理、いわゆる管理機関が必要です。現在の設定に変更が必要になると、管理機関が 1 か所で設定変更を行い、すべての対象システムに配布できます。集中管理システムには拡張性の高さと階層内での詳細さが要求されます。

セキュリティの視点からは、設定変更は通常、すべてのシステムに即時に適用されるものではないことを念頭に置いておく必要があります。とりわけ、レプリケーションのしくみの構成に依存します。集中セキュリティのしくみには、関係するプロセスについての深い技術的な理解が必要です。関係するしくみが複雑なため、管理者は細心の注意を払って変更を計画することをお勧めします。

管理機関は、承認された要素に対してのみ利用できます。企業ネットワークは通常、他の組織のネットワークと接続しており、インターネットにも接続できます。こうした環境で使用されるアカウントは、管理機関の制御下に入っていないため、このようなアカウントと接続することから発生するセキュリティ問題については、別の要素で扱う必要があります。

プライベート ネットワーク要素

プライベート ネットワーク要素は、2 社以上でプライベート ネットワークを共有する際に存在します。これはつまり、ローカル リソースにアクセスする特定の外部アカウント グループの責任を、別個の管理機関に与えるということです。ローカル リソースへのアクセスは、管理機関間での信頼関係で制御できます。プライベート ネットワーク要素は、企業間のネットワークを可能にすることでローカル ネットワークを拡張します。

セキュリティの観点からは、リモートの管理機関の制御下にあるアカウントを持つユーザーから、アクセス可能なデータの種類は、注意深く検討することが重要です。これらのアカウントから企業内ネットワークに直接アクセスできないようにネットワークを設定することをお勧めします。

インターネット構成要素

インターネット要素はインターネットに常時接続している企業ネットワークを表しています。インターネットに接続している人は誰でも、理論上は企業内のコンピュータと社内リソースにアクセスできることになります。

セキュリティ上の理由から、普通は、信頼できないユーザーがアクセスする可能性があるデータを含むサーバーは、システム内の別セグメントに置きます。この場所のことは外周部と呼ばれています (DMZ、Demilitarized Zones ともいいます)。この場所は通常、両側からファイアウォールで安全を確保されています。企業データへのアクセスは、このようなフロントエンド コンピュータから内部ネットワークへと確立されていきます。

内部の企業セキュリティが高度になるほど、侵入者がファイアウォール境界を越えて内部ネットワークへの進入に成功しても被害が起きるリスクは低くなります。境界の内側でのローカル リソースへのアクセスは、ローカル通信システムとエンド システム要素に属するセキュリティのしくみで制御されます。

要約すると、エンタープライズのセキュリティ構造は次のような要素に分けられます。

  • エンド システム (オペレーティング システムを含むコンピュータ ハードウェア機器)

  • ローカル通信システム (ネットワーク機能)

  • 管理機関 (集中セキュリティ管理)

  • プライベート ネットワーク (企業間のネットワーク共有)

  • インターネット

次の図で、今まで論じてきた概念要素と物理要素間の関係を要約しています。これらは構成要素と呼ばれ、"セキュリティ要素構成アーキテクチャ" の基礎を成すものです。

図 2: セキュリティ要素構成アーキテクチャ

ネットワークを概念的な構成要素の集合としてとらえる方法には、各要素を識別して個別に分けると、それぞれにセキュリティを実装することに集中できるという利点があります。またこれは、エンド システム要素から始まって連続的に、各構成要素が前段階の延長として動作する、ということを強調するのにも役立ちます。ある特定の環境に、ある特定の要素がないときは、それについての議論は飛ばして次の要素を対象に分析プロセスを進めることができます。

このフレームワークの目的は、すべての可能なシナリオに対して、レシピを用意することではありません。ただし、セキュリティのニーズとソリューションを探すための構造的な基盤を提供するので、実際のセキュリティ概念を開発する際に役立ちます。

ページのトップへ

セキュリティ ニーズ

ここまでで IT セキュリティの一般的な定義を行い、この定義を実現するための要素を取り出しました。これからのセクションの目的は、検討が必要なセキュリティ目標についてより詳細に説明することです。

攻撃の種類

セキュリティ サービスでは、悪意のある攻撃からリソースを保護するだけでなく、ユーザーが誤ってシステムに害を与えることを不可能にして、ユーザーが安心してシステムを使えることも意図しています。これら 2 つの保護から、セキュリティ サービスがまず対処する必要がある 2 つのカテゴリが導き出されます－－悪意のある攻撃と悪意のない攻撃です。

悪意のある攻撃

悪意のある攻撃の目標、方法、動機はさまざまですが、通常は、システムに危害を加えたい、または他の人が使えないようにしたいという、秘密裏に行われる活動です。以下に悪意のある攻撃をいくつか挙げます。

  • DOS (Denial of service) 攻撃は、システムの応答時間に悪影響を与えるか、または完全にシステムをつぶす目的で行われます。 この攻撃はインターネットでビジネスを行っている企業がしばしば対象になります。

  • ウィルスも、悪意のある攻撃の一種です。システムを攻撃する、多種多様なウィルスが存在しています。ウィルスを作ってばらまく人は、災いを引き起こし、ユーザーを驚かせ、重要なデータに損害を与えたいと思っています。ウィルスと DoS 攻撃の両方に共通しますが、通常、動機は個人的な利益を求めるのではなく、他の人の作業を中断させたりストップさせることにあります。

  • ハッカーまたはクラッカーによる攻撃は、悪意のある攻撃の第 3 のタイプです。このような人はパスワードを解析したり、転送中のメッセージ内容を変更しようとすることがあります。動機としては、弱点がないとされているコード障壁を突き破れることを単に証明したいだけのことが多く、そうして喜んでやっている攻撃のうちの一部には、まだ誰も気づいていないのです。

  • 個人的な利益を求める攻撃は、悪意のある攻撃の最後のタイプです。この場合には、攻撃者はデータを盗むか変更するためにネットワークへの侵入を試みます。このような攻撃者の例には、クレジット カード番号にアクセスしようとしたり、ビジネスの競争相手の計画や製品の情報を求めたり、EFT (電子送金) の送り先を別のアカウントに変更する人達があります。

悪意のない攻撃

重要なオペレーティング システム ファイルを誤って削除してしまうユーザーは、悪意のない攻撃をするタイプの人です。 機密データにアクセスするユーザーには、厳重に注意しておく必要があります。よくある方法では、たとえば、管理者は少なくとも 2 つのアカウントを持ち、管理アカウントは特別なセキュリティ デバイスで管理タスクを実行する際にだけ使うようにします。こうすれば事故を防ぐことができます。

攻撃からの復旧

攻撃を防ぐための手法とデバイスを取り入れる以外に、セキュリティ構想では、攻撃が成功した場合のシナリオについても検討しておく必要があります。100% 安全な環境を保証することは無理なので、リスクを見積もり、考えられる被害を最小限にする方法を計画することが望まれます。これにはバックアップも含まれるかもしれません。また、データ復旧とシステムの復元手順は確実に含めておくことをお勧めします。復旧手順は定期的にテストして、システムの復元とデータの可用性が現状に合っていて、効果があることを確かめる必要があります。

データの可用性

データの可用性はもっとも根本的なセキュリティです。データにアクセスできない場合でも、データの完全性については心配する必要がありません。ユーザーが必要とするデータ量は異なり、その緊急度も必要な時間もまちまちで、予測不可能なことがしばしばです。このため、セキュリティ管理者はデータが利用できない時間や、データ要求がすぐに実現されない時間を最小限にしたいと思っています。

データの可用性に影響を与える要因はいくつかあり、次のカテゴリに分けることができます。

  • 物理的セキュリティ

  • 冗長性

  • 緊急修復

物理的セキュリティ

重要なコンピュータは安全な環境に設置することをお勧めします。この環境では室温と湿度をメーカーの推奨仕様に保ちます。 大切なデータを保持している重要なサーバーを誰でも出入りできる場所に設置するのはよくありません。コンピュータのハードウェアは目に見えるデバイスで構成されているので、泥棒はシステムや情報を盗むために、コンピュータ サイエンスの詳細な知識を持っている必要がありません。コンピュータをそうした場所に設置すると、システムまたはデータを物理的に破壊し、可用性を下げる悪意にさらされやすくなります。

冗長性

冗長性またはフォールト トレラント性は、コンポーネントを二重に提供し、1 つ以上のコンポーネントが正しく動作しなくてもシステムを動作させ続けられる可用性をサポートします。システムの中で最も重要な部品は特にクローンとして実装することをお勧めします。 冗長なコンポーネントは、ハードウェアとソフトウェアのコンポーネントとして実装可能です。 ハードウェア コンポーネントの例は、ミラーリングをサポートするハード ディスクで、メインのハード ディスクが動作しなくなっても利用し続けることができます。 同様に DFS (Distributed File System) 共有は、同一の共有を異なるように見せかけるもので、いずれかがアクセスできなくなっても利用可能です。

緊急修復

データの回復の概念を含む手順のような、ある種の緊急修復手順は、冗長性の考え方を拡張したものです。侵入者が環境内のデータに損害を与えることができたとしても、緊急修復手順を使えば、最小限のデータ損失でシステムを "Last Known Good" 状態に戻すことができます。 ワークステーションが攻撃を受けた後で、元のきれいな状態に戻すための無人セットアップ方法の手順も用意しておくことをお勧めします。

セキュリティ概念の用語

これまでに論じてきたステップは、一般的なセキュリティ問題への回答です。ここからはもっと複雑なセキュリティ要求を見ていきます。これにはコンピュータ セキュリティのもっと微妙な用語を理解する必要があります。ある種の表現の正確な意味については合意が得られていないこともありますが、セキュリティ構想を定めているチーム内では用語の意味を統一しておくことをお勧めします。一般的な定義と変化形は、「The Consolidated Security Glossary of the National Institute of Standards and Technology (NIST)」 <https://www-08.nist.gov/posix/framework_wg/glossary.asc> にあります。以下のセクションではイタリック体でこれらを示しています。

データ保護プロセス

以前にも述べたとおり、最適なセキュリティ ソリューションには妥協がつきものです。最良のソリューションを決定するには、セキュリティ要件を詳細に特定することが非常に重要です。以下のセクションでは、これら要件について説明します。

識別 (Identification) と認証 (Authentication)

識別 : "要素の認識を IT 製品により可能とするプロセス"

認証 : "要素の識別を確立するプロセス"

適切な人だけがリソースにアクセスできることを保証するには、まずユーザーを識別する必要があります。これにはユーザーが自分の身分を証明する認証プロセスが必要です。このプロセスを識別ともいいます。これはログオン プロセス中に行われ、ある環境でデータにアクセスするために、最初にユーザーが行わなければならない最初のステップです。認証プロセスでは、ユーザーのユーザー名とパスワードをデータベースと照らし合わせて検証します。ユーザーがシステムに認証されて初めて、特定のデータベースのアクセス承認を要求することが可能になります。

このプロセスには多数の弱点があります。ユーザーの識別は通常、ユーザーが提供する 3 種類の情報を元にして行われます。

  • ユーザー名

  • パスワード

  • ログイン ドメイン

ユーザー名は一意の識別子であり、アカウント データベースに記録されていて、特定の環境下で、あるユーザーを別のユーザーと区別します。パスワードは、最も大事な制御のしくみです。これは同時にこのプロセスの弱点でもあります。ユーザーはログオンするときに思い出しやすい "簡単な" パスワードを使いがちだからです。

コンピュータ業界では、探しやすくて複製しやすいという、情報を識別する上での問題点を解決するために、いろいろな解決策を数多く用意しています。この解決策は "強いパスワード" を要件とすることから、スマート カード形式または指紋による ID 情報のバイオメトリック入力にまでわたっています。

アクセス制御 (Access Control)

"IT 製品のリソースへのアクセスを、権限のあるユーザー、プログラム、プロセス、システム、または他の IT 製品に制限するプロセス"

オペレーティング システムの主目的はシステム リソースの維持です。これらリソースにアクセスする操作はそれぞれ、アクセス制御手順を伴って設計されています。こうした内蔵型制御では "正しい人" だけがアクセスできることを保証してセキュリティをサポートしています。

一般にアクセス制御は、オペレーティング システムのプロセスを参照します。オペレーティング システムでは、与えられたリソースへのアクセス権を、リソースと関連づけられたアクセス制御一覧に基づいて検証します。セキュリティ機関は、リソースへの権限を決定するためにアクセス トークンをアクセス制御一覧の内容と比較します。アクセス制御プロセスは、システム リソースへのユーザーのアクセスを制限するだけでなく、プログラム、プロセス、システム、およびその他の IT 製品のアクセスも制限することに注意してください。

承認 (Authorization)

"あるセキュリティ オブジェクトへのアクセス許可"

"アクセス制御の決定がなされて執行されるプロセス"

承認がアクセス制御と関係して果たす正確な役割は、文献ではうまく定義されていません。共通している説明としては、承認は、認証プロセスのコンテキストで発生するということです。

ユーザーの認証が成功すると、オペレーティング システムは、ユーザー アカウントに割り当てられた権限 (たとえば "ローカルなログオン") を調べます。ユーザーがあるシステムにログオンする許可を与えられていることが、データベースからわかる場合は、ユーザーの ID (アクセス トークン) に権限が追加されます。

承認プロセスに対しては別の見方があります。これによれば、承認プロセスはアクセス制御のしくみが使用して、あるオブジェクトに対するユーザーのアクセス権を検証します。

また、あるドキュメントでは、承認は管理者がリソースへのアクセス権を許可するプロセスとして説明されています。

機密性 (Confidentiality)

"情報を未承認で公開することの防止"

"オブジェクトのセキュリティ プロパティにより次のことを防ぎます :

  • 存在が知られること、および / または
  • 内容が知られること"

"このプロパティは主題の知名度とも関係していますし、セキュリティ程度の合意度にも関係しています"

"情報が不適切な実体またはプロセスに公開されていないことの保証"

"未承認の個人、実体、またはプロセスに情報が利用可能となっていないか公開されていないというプロパティ"

機密性の目的はアクセス制御の目的と似ています。ただし、この用語は暗号と関係してよく使われています。暗号はネットワークのノード間で伝達される情報の保護に使用されます。暗号化された情報は符号化されているため、途中で傍受されてもすぐに理解されることはありません。最も広い意味での機密性では、アクセス制御の考え方を拡張して、データだけではなく、ユーザーが実行する操作内容をも公開しないようにします。

広い意味での機密性の重要性は、ユーザーが銀行と行うセッション内容を考えると理解できます。このセキュリティのしくみは、ユーザーが実行しているのが口座情報の照会なのか送金処理なのかを誰も見分けられないことを保証するものです。この面での機密性が欠如していると、ある種の動作に悪意のある攻撃が仕掛けられる可能性があります。

整合性 (Integrity)

"コンピュータ化されたデータがソース ドキュメントにあるものと同じで、偶然または悪意のある変更または破壊にさらされていないときの状態"

データの整合性は、他のセキュリティ サービスのための制御のしくみとして働いており、たとえばハード ディスクに格納されているデータと、"無線で" (ネットワーク上を) 飛び交うデータのアクセス制御がそれにあたります。セキュリティ上の目的は、気付かない間にデータが壊れていたり変更されている問題を解決することです。整合性サービスにより、メッセージの内容が変更されていないことを検証し、メッセージのシーケンスが転送されているときなら、シーケンスが正常であることを検証することで、問題が存在していないことを保証します。 データがネットワークを流れていき、オペレーティング システムのセキュリティ サービスでは保護できない場合に、これは特に重要です。

否認不能性 (Non-Repudiation)

"通信に関係していた実体が通信の全部または一部に参加していたことを否定"

この概念は特定メッセージの送信者の ID を証明するのに使用される機構を含むものです。 これは認証の拡張になりますが、通常は法的な目的で使用されます。この例としては、E コマース アプリケーションの中のしくみが挙げられます。ここではこのしくみは、送信者がメッセージ送信を否定したのは虚偽であることの証拠として、受取人が第三者 (判事または陪審員) に提出するのに使われます。

否認不能性に含まれるシナリオには、大きく分けて次の 4 つがあります。

  1. 送信者の証明 (送信元)。 あるユーザーからデータが送付されたことをその送信者が否定することから受信者を保護します。

  2. 送信の証明。送信者が実際にデータを送信したことを、誰かが否定することから送信者を保護します。

  3. 配信の証明。データが正しい宛先に配信されたことを、誰かが否定することから送信者またはサービス提供者、あるいは両方を保護します。

  4. 受信の証明。受信者がデータを受信したことを否定することから送信者を保護します。

ページのトップへ

構成要素の構造

以前のセクションで定義したセキュリティ要素は、このドキュメントで導入した SEBA (Security Entities Building Block Architecture) のフレームワークです。 これらの要素の各々－－または構成要素－－は問題点の内部構造が類似していて、セキュリティを適用するためにレビュー、分析、および実装を行う必要があるコンポーネントを含んでいます。 コンポーネント構成は似ているものの、各要素は異なる環境に対応しているため、具体的な問題点は少し異なります。

図 3 は、管理機関要素を安全にするために対処する必要があるコンポーネント群を示しています。

図 3: 管理機関の内部セキュリティ コンポーネント構造

以下のセクションでは、各要素内のコンポーネントの定義を上表の下から順に行います。

セキュリティ ポリシー

セキュリティ ポリシーは、ビジネス セキュリティ ニーズから導き出されます。 ポリシーは特定環境の基本タスクのルールを定義するもので、プログラム化されたプロセスの中で記述あるいは自動化できます。記述したポリシーは、システム ユーザーのアクションを導くことを目的とします。

可用性

可用性は今までにも述べたように、セキュリティの重要な側面です。 各要素は、通常、この要件を遂行するサービスを提供します。

可用性に関連するリスクを分析する最初のステップは、常にシステム全体に影響を与えない単独障害 SPOF (Single Points of Failure) を見つけだすことから始めて、SPOF が失敗したときにシステムに与える影響を評価することです。 SPOF の影響から、達成する必要がある可用性の程度を決定します。

可用性は通常、% でグレード付けを行います。 業務上重要なデータを搭載するシステムは、99.0 ～ 99.5% の範囲の可用性を提供できるように計画することをお勧めします。 99.95% 以上の要件は、高可用性要件とも言います。

認証

以前にも述べたように、認証は自動化したセキュリティ サービスで使用する基本的なしくみです。リソースにアクセスするたびに、認証プロセスの結果が使用されます。利用するしくみは、要素内で利用できる認証メソッドと識別メソッドの違いに応じて変化します。

リソース保護

知るべきでない人を情報から遠ざけておくのは、情報を単に秘密にしておく以上の努力が必要です。これには、情報が完全で、元のままで、壊れていないことを保証し、ユーザーが実行する操作の種類を誰も判断できないように保証することも含んでいます。

オペレーティング システムが提供する従来からのセキュリティ サービスは、リソースへのアクセスを制御する目的を持つ監視者の役割を果たします。これには承認とアクセス制御に含まれるすべての機能を含み、アクセス管理としてまとめることができます。これらのサービスは、オペレーティング システムがオンラインである場合に限って、作業を遂行できるので、アクティブなセキュリティを提供します。

ただし、これらのサービスだけでは、すべてのセキュリティ要件を満たしていません。NTFS パーティションをユーザーが読めるようにする MS-DOS 用のデバイス ドライバは、従来のオペレーティング システムのアクセス制御のしくみをバイパスするのに利用できるデバイスの例です。

最近のオペレーティング システムでは、暗号化という形で受動的なコンポーネントも提供しています。データの暗号化により、セキュリティのグレードが増加します。これは読めるデータ形式を取り出すのに余分なステップが必要で、アクセス管理の障壁をうまく通過した侵入者でもデータを読み出すのが難しくなります。 ただし、これらのサービスを使う際はよく検討する必要があります。これには特定のリソースの暗号化と解析処理に余分なコストが (少なくとも CPU サイクル負荷の形式で) 加わるからです。

セキュリティ分析

それぞれの要素には、監視とロギングが可能なカウンタ、またはその他の状況情報があります。与えられたシステムの現在のセキュリティ状況について意味のある情報を収集するには、注意深くシステムを構成する必要があります。このようなパラメータを構成し評価するプロセスは、セキュリティ分析として知られています。

セキュリティ ポリシー、可用性、認証、およびリソース保護がセキュリティを提供する方法であれば、セキュリティ分析は結果を測定する方法です。 セキュリティが重要な場合には、使用されているセキュリティのしくみの状態を検証する必要があります。 これにより、セキュリティ リスクの可能性をシステムが検出可能となります。次の 3 つのタスクは、セキュリティのしくみの状況を検証するのに利用されます。

  1. ロギング。典型的なログ エントリとしては、デバイス ドライバ障害、ネットワーク カードからのデータ エラー、またはログオン失敗のような項目を含みます。 ログはすべての処理トランザクションでとられていて、分析用に取り出すことができます。

  2. 中長期監視。ロギングのしくみで取り出される情報は、通常、何か悪い所があることだけを示すインジケータとしてのみ利用可能です。 問題の本質に迫るには、システムの特定の場所を監視する必要があるかもしれません。収集したデータはいろいろな方法で (たとえば、図表でグラフィカルに、またはテキストを使ってレポートとして) 表示して、特定のフォーカス、詳細、および必要な種類の説明を提供できます。監視データはリアルタイムに表示することも、ログに出力しておいて後から分析することも、切り分けの対象である問題に応じて可能です。

  3. **警告。**警告システムは、問題があることを管理者にリアルタイムに知らせ、修正アクションを開始する機会を提供します。

よく考慮して監視ツールを利用すると、管理者は企業のセキュリティとセキュリティ ポリシーの有効性に関する実質的なフィードバックが得られます。企業ネットワークの各要素内でセキュリティを達成するのに、セキュリティ ポリシーが出発点だとすれば、セキュリティ分析は、このプロセスを完結させ、全体の努力を仕上げるものです。

図 4: 各構成要素のセキュリティ コンポーネント

© 2000 Microsoft Corporation. All rights reserved.

このドキュメントに記載されている情報は、このドキュメントの発行時点におけるマイクロソフトの見解を反映したものです。 変化する市場状況に対応する必要があるため、このドキュメントは、記載された内容の実現に関するマイクロソフトの確約とはみなされないものとします。また、発行以降に発表される情報の正確性に関して、マイクロソフトはいかなる保証もいたしません。

このドキュメントは情報提供のみを目的としています。 明示または黙示に関わらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

Microsoft、MS-DOS、Windows、Windows NT、および Office ロゴ は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

ページのトップへ