この章では、セキュリティーの手法の概要、一般的なセキュリティー脅威、およびセキュリティーニーズ分析の手順の概要について説明します。
この章には、次の節があります。
製品のセキュリティーの詳細については、第 13 章「Messaging Server セキュリティーの計画」と第 18 章「Calendar Server セキュリティーの計画」を参照してください。
Communications Services 配備のセキュリティーは、「多重防御」手法を採用することによって管理します。ネットワーク、ハードウェアのプラットフォーム、オペレーティングシステム、アプリケーション自体を個々に安全にすることによって、アーキテクチャーの各層のセキュリティーを確保します。セキュリティーには、不必要なネットワークポートやアクセスメカニズムを閉鎖することによって各層を堅牢化する方法があります。また、インストールするソフトウェアパッケージの数を最小にして、システムが必要とするパッケージのみ利用できるようにします。最後に、ネットワーク内の意図しないアクセスから、層をセキュリティー保護するために層を隔離します。
Messaging Server のプロキシサーバーをインストールして、データセキュリティーを補強することができます。背後にある Messaging Server のファイアウォールに配置されたプロキシサーバーは、Messaging Server 上の情報に対する攻撃を防御します。
Calendar Server は、ユーザーを盗聴、不許可の使用、または外部からの攻撃から保護するためにいくつかのセキュリティーレベルを提供します。基本レベルのセキュリティーは認証によるものです。Calendar Server は、デフォルトの設定で LDAP 認証を使用していますが、代替の認証方法が必要とされる場合、認証プラグインの使用もサポートしています。Access Manager と統合すれば、Calendar Server はそのシングルサインオン機能を利用することができます。
Instant Messaging は、複数の認証メカニズムとセキュリティー保護された SSL 接続によって通信の統合を可能にします。Portal Server と Access Manager との統合によって、追加セキュリティー機能、サービスベースのプロビジョニングアクセスポリシー、ユーザー管理、セキュリティー保護されたリモートアクセスが可能になります。
完全かつセキュリティー保護された環境を確保するために、配備にはセキュリティー保護するホストの内部クロックを同期させる時間サーバーが必要です。
セキュリティー戦略の作成は、配備計画のなかで最も重要なステップの 1 つです。セキュリティー戦略は、組織のセキュリティーに対するニーズを満たし、ユーザーに不便を強いることなくセキュリティーが確保されたメッセージ環境を提供するものでなければなりません。
さらに、セキュリティー戦略は単純なものにして、管理を容易に行えるようにしておく必要があります。複雑なセキュリティー戦略を用いると、ユーザーがメールにアクセスできなかったり、ユーザーや権限のない侵入者によってアクセスされては困る情報が変更されたり、収集されたりする問題が生じます。
RFC 2196『Site Security Handbook』に記載されたセキュリティー戦略を構築するための 5 つのステップを、次に示します。
たとえば、保護対象のリストにはハードウェア、ソフトウェア、データ、従業員、文書、ネットワークインフラストラクチャー、または組織の評判などが含まれます。
何から保護するのかを判断します。
システムに対する脅威の可能性を推測します。
大規模なサービスプロバイダの場合、セキュリティーが脅威に晒される可能性は小規模な組織よりもはるかに高いといえます。さらに、組織の性格がセキュリティーに対する脅威を誘発することも考えられます。
費用対効果の高い方法で資産を守る対策を導入します。
たとえば、SSL 接続を設定する際のオーバーヘッドによって、メッセージング配備のパフォーマンスに対する負荷が発生する可能性があります。セキュリティー戦略を設計するうえで、セキュリティーニーズとサーバーの能力のバランスを取る必要があります。
戦略を常時見直し、弱点が発見されるたびに戦略を練り直して、よりすぐれたものに改善します。
定期的な監査を行い、セキュリティーポリシーの全体的な有効性を検証します。監査は、ログファイルと SNMP エージェントが記録した情報を調査することで行います。SNMP の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。
セキュリティー戦略では、次の項目についても計画する必要があります。
インフラストラクチャーの重要な部分への物理的なアクセスを制限します。たとえば、ルーター、サーバー、配線クローゼット、サーバールーム、データセンターを、窃盗、改竄、その他の悪用から保護するために、物理的な制限を設けます。権限を持たない人物にサーバールームへの侵入を許し、ルーターの配線を抜かれることがあるようでは、ネットワークとサーバーのセキュリティーも無意味なものとなります。
重要なオペレーティングシステムアカウントとデータへのアクセスを制限することも、セキュリティー戦略の一部となります。この保護は、オペレーティングシステムで利用できる認証とアクセス制御のメカニズムにより行われます。
さらに、最新のオペレーティング環境のセキュリティーパッチをインストールし、数ヶ月ごとに、またベンダーからのセキュリティー警告に対応して、パッチを更新する必要があります。
運用環境におけるセキュリティー違反の潜在的リスクを軽減するために、「システムの堅牢化」と呼ばれる次の方法を実行します。
運用環境におけるインストールの最小化: インターネットまたは信頼されていないネットワークに開放されている環境に Sun サーバーをインストールするときに、アプリケーションをホストするのに必要な最小限の数まで、Solaris ソフトウェアのインストールパッケージを減らすことができます。サービス、ライブラリ、およびアプリケーションの数を最小化することにより、保守が必要なサブシステムの数が減少し、セキュリティーの向上につながります。
Solaris Security Toolkit は、Solaris システムを最小化し、強化し、セキュリティー保護されたシステムにするための、柔軟性と拡張性に富んだメカニズムを提供します。このツールキットの配備の背後にある主な目的は、Solaris システムのセキュリティーを確保するプロセスを簡素化し、自動化することです。詳細については、次の Web サイトを参照してください。
ファイルシステムの変更の追跡と監視: セキュリティーの組み込みが必要なシステム内では、ファイル内の変更を追跡し、危険性のある侵入を検出するためにファイル変更制御および監査ツールが不可欠です。Tripwire for Servers または Solaris Fingerprint Database (SunSolve オンラインで入手可能) などの製品を使用できます。
水平方向のスケーラビリティーとサービスのセキュリティーの両方をサポートするには、ファイアウォールの背後にアーキテクチャーのアクセス層を配置する配備構成をお勧めします。2 層アーキテクチャーでは、2 つのファイアウォールを使用して DMZ を作成します。これは、2 番目のファイアウォールの背後にある内部ネットワークのメインサービス要素を保護しながら、情報配信要素、カレンダおよびメッセージングフロントエンドへのアクセスを可能にします。また、このような構成は、アクセス層とデータ層の要素を個別に拡大縮小して、トラフィックおよびストレージ要素に対応することができます。
ネットワークへのアクセスを制限することは、セキュリティー戦略の重要なポイントとなります。通常は、ファイアウォールを使用してネットワークへの全般的なアクセスを制限します。ただし、電子メールはサイト外から使用できるようにしておく必要があります。SMTP がそのサービスの 1 つに該当します。
ネットワークのセキュリティーを確保するには、次の条件が必要となります。
使用しないポート上で待機している、オペレーティングシステムが提供するすべてのサービスを停止します。
可能な場合は、telnet を sshd に置き換えます。
パケットフィルタで内部発信元 IP アドレスを持つ外部パケットを拒否し、その背後にアプリケーションサーバーを配置します。パケットフィルタは、明示的に指定したポート以外に向けたすべての外部接続を遮断します。
Messaging Server には、次のセキュリティー機能があります。
配備におけるメッセージングコンポーネントの保護
このオプションセットにより、MTA リレー、メッセージストア、Messenger Express メールクライアント、および多重化サービスのセキュリティーが確保されます。さらに、サードパーティーのスパムフィルタオプションについてもわかります。
ユーザー認証の計画
これらのオプションを使用して、メールサーバーでユーザーが認証される仕組みを決定し、権限を持たないユーザーがシステムにアクセスするのを防ぐことができます。
セキュリティーに関する誤解
このオプションセットを使用すると、認証された SMTP とデジタル署名の証明書、暗号、SSL (Secure Sockets Layer) によるユーザー認証とメッセージの保護を行うことができます。
詳細については、第 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 を使用しなければなりません。このソリューションは、パートナーとの間のほかのトラフィックを考慮しておりません。ただし、通常、メールはトラフィックの大きな部分を占めており、企業は転送されるデータに基づいて料金を支払うことができるので、公衆インターネットの使用はコストが少なくて済みます。
サーバーとクライアント間、たとえば、Messaging Server から配備したほかのサーバー間に SSL 接続を実装することができます (Web Server、Calendar Server、Directory Server も同様)。必要に応じて、サーバー用とクライアント用に 2 つの認証局 (CA) を使用することができます。
このシナリオでは、ある CA を使用してサーバー証明書を発行し、別の CA を使用してクライアント証明書を発行します。クライアントにサーバーの証明書が本物であることを承認させたい場合は、サーバーの CA 証明書をクライアントの証明書 DB にロードする必要があります。サーバーにクライアントの証明書が本物であることを承認させたい場合は、クライアントの CA 証明書をサーバーの証明書 DB にロードする必要があります。
この節では、配備のセキュリティーニーズに対して逆効果になる、典型的な誤解について説明します。
製品名とバージョンを隠す:
製品名とバージョンを隠しても、即席の攻撃者の邪魔をする程度でしかありません。最悪の場合は、管理者にセキュリティーに関する誤った感覚を与えることになり、本当のセキュリティー問題の追跡を怠るという結果になりかねません。
事実、製品情報とバージョン番号が削除されると、ソフトウェアの識別ができなくなるため、ベンダーのサポート部門がソフトウェアの問題を検証するのが困難となります。
ハッカーが選択的な行動を取ることはほとんどありません。特に、SMTP サーバーに既知の脆弱性があれば、彼らはあらゆる SMTP サーバーにアクセスを試みるかもしれません。
内部マシン名を隠す:
内部 IP アドレスとマシン名を隠すことで、次のことが困難になります。
悪用またはスパムの追跡
メールシステムの設定エラーの診断
DNS 設定エラーの診断
知識のある攻撃者であれば、一度ネットワークに侵入する方法を見つければ、マシンのマシン名と IP アドレスを簡単に見つけ出します。
SMTP サーバーの EHLO をオフにする:
EHLO を使用すると、SMTP クライアントは、制限の有無と、この応答を受けるとすぐに制限を超えたメッセージの送信を停止するかどうかを判断します。ただし、EHLO がオフになっているため HELO を使用しなければならない場合は、送信側の SMTP サーバーはメッセージデータ全体を送信し、その後メッセージサイズが制限を超えているため拒否されたことを通知されます。その結果、処理サイクルとディスク容量の無駄が発生します。
Network Address Translation (NAT)
NAT を一種のファイアウォールとして使用する場合は、システム間でエンドツーエンドの接続を行うことはできません。その代わり、中間に第三のノードを置くことになります。この NAT システムは仲介役として機能し、潜在的なセキュリティーホールの原因になります。
セキュリティー保護された Communications Services 配備の設計について、詳しくは Computer Emergency Response Team (CERT) Coordination Center のサイトを参照してください。