データの分類

アプリケーションの分析と、その適切なレベルへの分類を完了したら、次に、これらのアプリケーションから提供されるデータおよびサービスの分類を開始する必要があります。この情報は、セキュリティーモデルの構築に使用されます。分類自体は、データおよびサービスを分類するプロセスです。それに続き、既存の認証および承認システムのカタログ作成が行われます。

この前者のプロセスに、アプリケーションの評価で収集された情報が使用されます。収集した情報をさまざまなセキュリティー層に編成するのは、良い方法です。これらの層は、データの紛失、アプリケーションの妥協的使用、誤用、その他の不正なアクセスタイプに関係したリスクの量を示すものとなります。正しく定義されたカテゴリを使用すると、リソースをセキュリティモデルにマッピングして、認証および承認要件を組み込む作業が簡単になります。

データまたはサービスは、4 つのセキュリティレベルに分類されます。X 軸はデータまたはサービス、Y 軸は関連付けられるセキュリティレベルを表します。層 1 は、セキュリティーが最小であることを示します。これは、公開された Web サイトに適用可能なデータです。一方、層 4 は、セキュリティーが最大であることを示します。これは財務や人事 (HR) データなどに適用されます。実際の組織の分類に使用される層はこれより多い場合も少ない場合もありますが、この図は、大量のデータには関連するリスクも低く、そのためセキュリティー要件も少なくなるという典型的な例を示しています。関連するリスクが大きくなるにつれ、セキュリティー要件も多くなります。通常、高度なセキュリティー要件が必要なデータはごくわずかであり、多くのデータはセキュリティー要件をほとんど必要としません。

次の図は、典型的な組織内のデータおよびサービスのセキュリティー要件を示しています。

図 2–1 データおよびサービスのセキュリティー要件

認証および承認機能を割り当てることができるように、データおよびサービスタイプの機能グループを構築しようとしていることを念頭に置いてください。層の数が多すぎるとプロセスが過度に複雑になり、層の数が少なすぎると柔軟性に欠けたものになります。さらに、ネットワーク上に配置すること自体が非常に危険なデータもあることも考慮しておくことは重要です。可能な場合は、内部で利用可能なデータと外部で利用可能なデータを明確に区別するようにしてください。これらの層を構築する際、認証および承認要件とともに、データのアクセス時刻およびネットワーク上の位置などの修飾条件も念頭に置くようにしてください。

認証へのマッピング

データをセキュリティーレベルに応じて分類できたら、次の段階は、認証および承認メカニズムの一覧を作成することです。利用可能な認証メカニズムに関する手持ちのリストを使用して、これらのメカニズムを定義済みのセキュリティー層に関連付けます。たとえば、次の関連付けは、前の図で分類されたデータに対応しています。

• 層 1 のデータは、アクセス制御なしの匿名認証が適切と考えられます。

• 層 2 のデータは、パスワード保護のみを必要とします。

• 層 3 のデータは、ハードトークンまたは証明書認証が必要です。

• 層 4 のデータは、マルチファクター認証を必要とします。または、ネットワーク上には絶対に配置しないようにします。

認証要件とデータやサービスの分類とのマッピングが、単純で明快なものであるようにしてください。そうでない場合、一致しない項目間で共通の基準を見つけるようにしてください。論理的な差異が存在するなら、ためらわずに複数の図を作成してください。

たとえば、イントラネットとエクストラネット用のアプリケーションでは、それぞれ別個の図を作成できます。また、人事 (HR) や財務などの機能セキュリティドメインに基づいて、データを分類することもできます。このようなデータ分類手法は万能とは言えませんが、セキュリティー要件を理解し、論理的に管理可能なグループにマッピングする場合に役立ちます。

承認へのマッピング

アプリケーション評価により入手したデータを使用して各アプリケーションを検証し、スケーラブルな承認モデルを決定します。通常、最善の方法は、複数のアプリケーションにわたって使用する共通のグループやロールを見つけることです。これらのグループやロールが、組織内の機能ロールにマッピングされていると理想的です。また、これらのグループやロールのソース (メンバーシップデータの存在位置およびそのモデリング方法) を判別する必要もあります。たとえば、データは Sun Java System Directory Server 内に存在する可能性があります。

存在しない場合は、カスタムプラグインが必要になる場合があります。堅牢なグループモデルが存在する場合、最初に、各アプリケーションを既存のグループまたはロールに関連付けてください。存在しない場合は、最初にロールまたはグループメカニズムを計画し、機能的観点からユーザータイプ間の共通の関係を見つけてから、特定のアプリケーションにとりかかります。作業の完了時点で、以下のものが入手できます。

• 既存のグループおよびロールの明確なマッピング

• データの存在する位置、その品質と管理に関する権限を持つ人物に関する明確な理解

• 配備を促進したり、配備のコストや複雑性を低減したりするために作成する必要のある新しいグループまたはロールについての明確な理解

• 既存および将来のグループメカニズムの、分類されたアプリケーションへのマッピング

• 特定のグループやロールへのアクセスを可能にするため、アプリケーションが必要とする追加条件に関する注意事項

この基本的なセキュリティーモデル (認証および承認メカニズムとの関連を利用したデータの分類) を使用して、配備を実行するスケジュールをまとめることができます。