test

Sun Java System Communications Services 6 2005Q4 配備計画ガイド

セキュリティー戦略の作成

セキュリティー戦略の作成は、配備計画のなかで最も重要なステップの 1 つです。セキュリティー戦略は、組織のセキュリティーに対するニーズを満たし、ユーザーに不便を強いることなくセキュリティーが確保されたメッセージ環境を提供するものでなければなりません。

さらに、セキュリティー戦略は単純なものにして、管理を容易に行えるようにしておく必要があります。複雑なセキュリティー戦略を用いると、ユーザーがメールにアクセスできなかったり、ユーザーや権限のない侵入者によってアクセスされては困る情報が変更されたり、収集されたりする問題が生じます。

RFC 2196『Site Security Handbook』に記載されたセキュリティー戦略を構築するための 5 つのステップを、次に示します。

  1. 何を保護するのかをはっきりさせます。

    たとえば、保護対象のリストにはハードウェア、ソフトウェア、データ、従業員、文書、ネットワークインフラストラクチャー、または組織の評判などが含まれます。

  2. 何から保護するのかを判断します。

    例: 権限のないユーザー、スパマー、またはサービス拒否攻撃

  3. システムに対する脅威の可能性を推測します。

    大規模なサービスプロバイダの場合、セキュリティーが脅威に晒される可能性は小規模な組織よりもはるかに高いといえます。さらに、組織の性格がセキュリティーに対する脅威を誘発することも考えられます。

  4. 費用対効果の高い方法で資産を守る対策を導入します。

    たとえば、SSL 接続を設定する際のオーバーヘッドによって、メッセージング配備のパフォーマンスに対する負荷が発生する可能性があります。セキュリティー戦略を設計するうえで、セキュリティーニーズとサーバーの能力のバランスを取る必要があります。

  5. 戦略を常時見直し、弱点が発見されるたびに戦略を練り直して、よりすぐれたものに改善します。

    定期的な監査を行い、セキュリティーポリシーの全体的な有効性を検証します。監査は、ログファイルと SNMP エージェントが記録した情報を調査することで行います。SNMP の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

セキュリティー戦略では、次の項目についても計画する必要があります。

物理的なセキュリティー

インフラストラクチャーの重要な部分への物理的なアクセスを制限します。たとえば、ルーター、サーバー、配線クローゼット、サーバールーム、データセンターを、窃盗、改竄、その他の悪用から保護するために、物理的な制限を設けます。権限を持たない人物にサーバールームへの侵入を許し、ルーターの配線を抜かれることがあるようでは、ネットワークとサーバーのセキュリティーも無意味なものとなります。

サーバーセキュリティー

重要なオペレーティングシステムアカウントとデータへのアクセスを制限することも、セキュリティー戦略の一部となります。この保護は、オペレーティングシステムで利用できる認証とアクセス制御のメカニズムにより行われます。

さらに、最新のオペレーティング環境のセキュリティーパッチをインストールし、数ヶ月ごとに、またベンダーからのセキュリティー警告に対応して、パッチを更新する必要があります。

オペレーティングシステムのセキュリティー

運用環境におけるセキュリティー違反の潜在的リスクを軽減するために、「システムの堅牢化」と呼ばれる次の方法を実行します。

ネットワークセキュリティー

水平方向のスケーラビリティーとサービスのセキュリティーの両方をサポートするには、ファイアウォールの背後にアーキテクチャーのアクセス層を配置する配備構成をお勧めします。2 層アーキテクチャーでは、2 つのファイアウォールを使用して DMZ を作成します。これは、2 番目のファイアウォールの背後にある内部ネットワークのメインサービス要素を保護しながら、情報配信要素、カレンダおよびメッセージングフロントエンドへのアクセスを可能にします。また、このような構成は、アクセス層とデータ層の要素を個別に拡大縮小して、トラフィックおよびストレージ要素に対応することができます。

ネットワークへのアクセスを制限することは、セキュリティー戦略の重要なポイントとなります。通常は、ファイアウォールを使用してネットワークへの全般的なアクセスを制限します。ただし、電子メールはサイト外から使用できるようにしておく必要があります。SMTP がそのサービスの 1 つに該当します。

ネットワークのセキュリティーを確保するには、次の条件が必要となります。

メッセージングセキュリティー

Messaging Server には、次のセキュリティー機能があります。

詳細については、第 13 章「Messaging Server セキュリティーの計画」を参照してください。

アプリケーションのセキュリティー

Communications Services 製品ポートフォリオは、業務用通信のセキュリティーと統合を実現する機能を提供します。Communications Services は、次のような幅広い「組み込み」セキュリティー機能を提供します。

セキュリティー保護された接続の実装

Communications Services は、SSL/TLS、S/MIME 、SAML などのセキュリティー標準をサポートします。SSL/TLS を使えば、クライアントとサーバー間のすべての通信を暗号化されたセッション内で行えます。Portal Server と統合すれば、追加の認証メカニズムがデフォルトで利用可能になるほか、アプリケーション全体にわたってシングルサインオン機能を利用できるようになります。

注 –

Web サーバー内の Communications Express アプリケーションと Calendar Server の cshttpd デーモン間では、SSL はサポートされていません。

公開鍵データセキュリティーを実装する場合は、公開鍵インフラストラクチャーと鍵の選択をサポートするメールクライアントを選択する必要があります。Communications Services 製品は、追加の設定なしで、このように暗号化されたメッセージの転送と保管に直ちに関わることができます。Communications Express Mail クライアント上では、S/MIME (Secure/Multipurpose Internet Mail Extension) を利用できます。S/MIME を使用するように設定された Communications Express Mail ユーザーは、Communications Express Mail、Microsoft Outlook Express、および Mozilla メールシステムを使用するほかのユーザーと、署名または暗号化されたメッセージを交換できます。

注 –

以前のバージョンの Messaging Server に含まれる Web メールクライアントは、暗号化されたメッセージを生成したり復号化したりできません。

一般的に使用されるデータセキュリティーのメカニズムは、さまざまなメッセージングエージェント間のデータ送信に使用する接続で SSL 暗号化を使用して、配線間 (つまり、クライアントからサーバーまで) のデータだけを保護します。このソリューションは、公開鍵暗号化ほど完全ではありませんが、実装がはるかに容易で、数多くの製品とサービスプロバイダによってサポートされています。

クライアントからサーバーまで SSL を使用することにより、どんな問題が解決するでしょうか。組織は、所有するコーポレートネットワークを制御し、そのネットワーク上で送信されるデータは社員以外の者からは安全であるとみなされています。コーポレートネットワークの外部から企業のインフラストラクチャーを使用して送信されるメールは、暗号化接続を介して企業のネットワークにデータを送信します。同様に、コーポレートネットワークの外部の企業ユーザーが受信するすべてのメールは、暗号化接続を介して送信されます。したがって、内部ネットワークの安全に関する企業の仮定が正しく、社員が自分自身とほかの社員間の転送用に認定されたサーバーだけを使用する場合には、社員間のメールは外部攻撃から安全に保護されています。

このソリューションではどんな問題が解決されないか。まず最初に、この方法では、組織の内部ネットワークにアクセスした受信者以外のユーザーが偶然にもデータを参照してしまうことを防げません。次に、社員と外部パートナー、顧客、または供給業者間で送信されるデータの保護が行われません。データは、完全にセキュリティー保護されていない状態で公衆インターネット間を移動します。

ただし、この問題は、企業と顧客の両方のネットワークの MTA ルーター間の SSL 暗号化設定によって修正することができます。この種類のソリューションは、使用する各私設接続の設定が必要になります。このためには、メールを介して送受信する顧客またはパートナーのデータにセキュリティーのための重要な層を追加します。Communications Services の MTA と SSL を使用することにより、企業は送信手段として公衆インターネットを使用してコストの節約ができますが、MTA は パートナーの SSL を使用しなければなりません。このソリューションは、パートナーとの間のほかのトラフィックを考慮しておりません。ただし、通常、メールはトラフィックの大きな部分を占めており、企業は転送されるデータに基づいて料金を支払うことができるので、公衆インターネットの使用はコストが少なくて済みます。

2 つの異なる認証局 (CA) を使用するセキュリティー保護された接続の実装

サーバーとクライアント間、たとえば、Messaging Server から配備したほかのサーバー間に SSL 接続を実装することができます (Web Server、Calendar Server、Directory Server も同様)。必要に応じて、サーバー用とクライアント用に 2 つの認証局 (CA) を使用することができます。

このシナリオでは、ある CA を使用してサーバー証明書を発行し、別の CA を使用してクライアント証明書を発行します。クライアントにサーバーの証明書が本物であることを承認させたい場合は、サーバーの CA 証明書をクライアントの証明書 DB にロードする必要があります。サーバーにクライアントの証明書が本物であることを承認させたい場合は、クライアントの CA 証明書をサーバーの証明書 DB にロードする必要があります。