セキュリティー・ポリシーと目的

セキュリティー・ポリシーでは、保護する必要があるものを定義し、 セキュリティーの目的では、ユーザーに期待することを表します。

セキュリティー・ポリシー

インターネット・サービスを使用または提供するたびに、 システムと、システムが接続されているネットワークがリスクにさらされます。セキュリティー・ポリシーとは、 組織に所属するコンピューターおよび通信リソースに対する操作に適用される規則の集まりです。 これらの規則は、物理的セキュリティー、人的セキュリティー、管理セキュリティー、および ネットワーク・セキュリティーなどの領域にわたります。

セキュリティー・ポリシーでは、 保護する必要があるもの、およびシステム・ユーザーに期待することを定義します。 セキュリティー・ポリシーは、新規アプリケーションを設計したり、現行のネットワークを拡張する場合に、セキュリティー計画の基盤を提供します。 セキュリティー・ポリシーには、機密情報の保護や重要なパスワードの作成など、ユーザーが行わなければならない作業が記述されます。 セキュリティー・ポリシーには、セキュリティー措置の効果をモニターする方法も 記述しなければなりません。 このようなモニターは、 安全防護柵をすり抜けようとする人物がいるかどうかを判別するのに役立ちます。

セキュリティー・ポリシーを開発するには、セキュリティーの目的を明確に定義しなければなりません。 セキュリティー・ポリシーを策定したら、そこに含まれる規則を実行に移すためのステップを取らなければなりません。 これらのステップでは、規則を施行するために、従業員の訓練、必要なソフトウェアおよびハードウェアの追加が行われます。 また、コンピューター環境を変更する場合は、セキュリティー・ポリシーを更新しておかなければなりません。これは、 変更によって生じる可能性がある新しいリスクに対処するためです。

セキュリティーの目的

セキュリティー・ポリシーを作成および実行するには、目的を明確にしておかなければなりません。 セキュリティーの目的は、次に示すカテゴリーの 1 つ以上に分類されます。

リソース保護
リソース保護により、許可ユーザーしかシステムのオブジェクトにアクセスできないようにします。 あらゆる種類のシステム・リソースを保護できるということが、 System i® の長所の 1 つです。 システムにアクセス可能なユーザーのさまざまなカテゴリーを注意深く定義する必要があります。 また、セキュリティー・ポリシー作成の一環として、これらのグループの ユーザーにどのようなアクセス権を与えるかを定義しなければなりません。
認証
セッションの相手のリソース (人またはマシン) が、実際に当の本人またはマシンであることを確認または検査すること。 堅固な認証により、偽名を使用してシステムを使用するというセキュリティー・リスクから保護してくれます。 このように偽名を使う場合、送信者または受信者は、偽の ID を使用してシステムにアクセスします。 従来、システムでは認証にパスワードとユーザー名を使用してきました。 ディジタル証明書では、さらに安全な認証方法を使用することができると同時に、他にもセキュリティー上の利点があります。 インターネットのような公衆ネットワークにシステムをリンクする場合は、ユーザー認証が新しい次元を引き受けます。 イントラネットがインターネットと異なる重要な点は、サインオンするユーザーの身元を信用できることです。 したがって、従来のユーザー名とパスワードによるログオン手続きによる認証よりも、さらに強力な認証方法の採用を真剣に考えなければなりません。 認証されたユーザーは、その許可レベルに基づいて、さまざまな種類の権限が認められます。
許可
セッションの相手の人またはコンピューターが、要求を実行する許可を持っていることを確認すること。 許可は、システム・リソースへのアクセス権を持つ、 またはシステムにおける操作を実行できる人またはものを決定するプロセスです。 通常、許可は、認証のコンテキスト内で実行されます。
保全性
着信情報がその送信情報と同一であることを確認すること。保全性を理解するには、データの保全性とシステムの保全性の概念を理解しておかなければなりません。
  • データ保全性: データが未認証の変更または損傷から保護されていることです。 データ保全性により、許可されていない者が情報を代行受信したり変更するというセキュリティー・リスクから保護されます。 ネットワーク内に保管されているデータの保護の他に、信頼性に欠けるソースのデータがシステムに進入してきた場合に、 データ保全性を保証するセキュリティーがさらに必要になることもあります。 システムに入ってくるデータが公衆ネットワークからのものである場合は、 以下のようなことを可能にするためのセキュリティー方式が必要になることがあります。
    • データが監視されたり解釈されたりするのを防ぎます。 通常、これには暗号化を伴います。
    • 伝送が変更されていないことを保証します (データ保全性)。
    • 伝送が行われたことを証明します (否認防止)。 将来は、登録済みまたは証明済みメールの電子的な等価物が必要になるかもしれません。
  • システム保全性: 予期されるパフォーマンスで、システムが一貫性のある、予期される結果を生み出すことです。i5/OS™ オペレーティング・システムの場合、 システムの保全性は、最も見落とされがちなセキュリティー要素です。 それは、システムの保全性が、i5/OS アーキテクチャーの基本的な部分だからです。 例えば、セキュリティー・レベルを 40 または 50 にしていると、 i5/OS アーキテクチャーは、 ハッカーにとって、オペレーティング・システムのプログラムをまねたり、変更するのがきわめて難しくなります。
否認防止
トランザクションが発生したこと、あるいはメッセージを送信または受信したことを証明するものです。トランザクション、メッセージ、および ドキュメントに署名するためのデジタル証明書と公開鍵暗号は、否認防止をサポートしています。 送信側および受信側の両者が、交換が行われたことに同意します。データ上の ディジタル署名が、必要な証明を提供します。
機密性
機密情報がプライベートのままで、盗聴者からは守られていることを確認すること。機密性は総合的なデータ・セキュリティーにとって重要です。 非トラステッド・ネットワークでデータを転送する場合は、デジタル証明書と Secure Sockets Layer (SSL) によるデータの暗号化、または仮想プライベート・ネットワーク (VPN) 接続によって機密性を確保することができます。 セキュリティー・ポリシーでは、ネットワーク内の情報と、 ネットワークから出て行く場合の情報に対してどのように機密性を提供するかについて言及していなければなりません。
セキュリティー活動の監査
セキュリティー関連のイベントをモニターして、成功アクセスも不成功 (拒否) アクセスも記録します。 成功アクセス・レコードは、システムで誰が何を行っているかを示します。不成功 (拒否) アクセス・レコードは、セキュリティーを破ろうとしたか、 あるいはシステムへのアクセスに悪戦苦闘しているものがいることを知らせます。