システム・セキュリティについて

Oracle Linuxでのシステム・セキュリティの概要

Oracle Linuxには、ネットワーク・ファイアウォール制御からアクセス制御セキュリティ・ポリシーまで、完全なセキュリティ・スタックが用意されており、デフォルトでセキュアに設計されています。

従来のLinuxのセキュリティは、壊れたソフトウェアからの最小限の保護、または通常ユーザーあるいはrootとして実行されるマルウェアからの最小限の保護を提供する、任意アクセス制御(DAC)ポリシーに基づいていました。LinuxカーネルのSELinux拡張により、強制アクセス制御(MAC)ポリシーが実装され、すべてのユーザー、プログラム、プロセス、ファイル、デバイスに詳細な権限を提供するセキュリティ・ポリシーを定義できるようになりました。カーネルのアクセス制御の決定は、認証されたユーザーIDだけでなく、利用可能なすべてのセキュリティ関連情報に基づいて行われます。デフォルトでは、Oracle Linuxシステムをインストールすると、SELinuxが有効になります。

Oracle Linuxは、ビジネスクリティカルな本番環境に必要なパフォーマンス、データ整合性、アプリケーション稼働時間を提供できる、セキュアなエンタープライズクラスのオペレーティング・システムへと進化しています。

Oracleの何千もの本番システムでOracle Linuxが実行されており、多数の社内開発者が開発プラットフォームとしてOracle Linuxを使用しています。Oracle Linuxはまた、Oracle Exadata Database Machine、Oracle Exalytics In-Memory Machine、Oracle Exalogic Elastic Cloud、Oracle Database ApplianceなどいくつかのOracle Engineered Systemsの中核をなしています。

Oracleデータ・センターを介して顧客サイトで、またはパートナ・サイトで、サービスとしてのソフトウェア(SaaS)を提供するOracle On Demandサービスは、ソリューション・アーキテクチャの基盤としてOracle Linuxを使用しています。Oracleサポートに支えられて、これらのミッションクリティカルなシステムおよびデプロイメントは、Oracle Linuxオペレーティング・システムに組み込まれているセキュリティおよび信頼性の機能に本質的に依存しています。

オープンソース・ライセンスでリリースされるOracle Linuxは、テスト済のパフォーマンスと安定性を提供する一方で、最新のLinuxイノベーションズを提供するUnbreakable Enterprise Kernelを搭載しています。OracleはLinuxコミュニティの主要メンバーであり、Oracle Cluster File SystemやBtrfsファイル・システムなどのコード拡張に貢献しています。セキュリティの観点から、オープン・ソースをルーツにしていることは大きな利点となっています。Linuxコミュニティの数多くの経験豊富な開発者やセキュリティ・エキスパートが、投稿されたLinuxコードを、テストやリリースを行う前に広範囲にわたってレビューします。オープンソースのLinuxコミュニティは長年にわたって、アクセス制御リスト(ACL)、暗号ライブラリ、信頼できるユーティリティなど、数多くのセキュリティの改善を提供してきました。

Oracle Linux環境について

セキュリティ・ニーズを適切に把握するために、次の質問を問いかけてみます。

保護しているのはどのリソースですか。: WebLogic Serverからアクセスするデータベースの情報、およびWebサイトの可用性、パフォーマンス、アプリケーションおよび整合性を含め、本番環境の多くのリソースを保護できます。提供すべきセキュリティ・レベルを決定する際には、保護対象のリソースを考慮します。
リソースを誰から保護していますか。: ほとんどのWebサイトでは、インターネット上のすべてのユーザーからリソースを保護する必要があります。しかし、Webサイトを企業のイントラネット上の従業員から保護する必要はあるでしょうか。従業員はWebLogic Server環境内のすべてのリソースへのアクセス権を持つ必要があるでしょうか。システム管理者はすべてのWebLogicリソースへのアクセス権を持つ必要があるでしょうか。システム管理者はすべてのデータにアクセスできる必要があるでしょうか。機密性の高いデータや戦略的リソースへのアクセス権は、信頼できる少数のシステム管理者にのみ付与することを検討できます。システム管理者に、このようなデータまたはリソースへのアクセスを許可しないことがベストでしょう。
戦略上重要なリソースの保護に失敗したらどうなりますか。: セキュリティ・スキームのエラーが容易に検出され、単に不便を与えるだけのこともあります。また、エラーが会社またはWebサイトを利用する個々のクライアントに大きなダメージを与えることもあります。各リソースのセキュリティの問題を把握することは、リソースを適切に保護するのに役立ちます。

推奨されるデプロイメント構成

この項では、セキュアなインターネット・アクセスによってOracle製品をデプロイするための推奨アーキテクチャについて説明します。

図1-1に、単純なデプロイメント・アーキテクチャを示します。

図1-1 単純なファイアウォール・デプロイメント構成

図は、単一のファイアウォールによってインターネットから隔離された単一システムを示しています。矢印は、外部ブラウザからファイアウォールを介してターゲット・システムに接続する方向を示しています。

この単一コンピュータ・デプロイメントは、小規模な組織では経済的です。しかし、すべてのコンポーネントが同一コンピュータ上に格納されるため、高可用性は実現できません。

図1-2に、よく知られている一般に認められたインターネット-ファイアウォール-DMZ-ファイアウォール-イントラネット・アーキテクチャを使用する推奨構成を示します。

図1-2 DMZデプロイメント構成

この図では、外部ブラウザからターゲット・システムへの接続方向は同じです。ただし、この接続は、ファイアウォールによってインターネットとイントラネットの両方から隔離された非武装地帯(DMZ)を通過します。これは、両者間のバッファの役目を果たします。

非武装地帯(DMZ)とは、ファイアウォールによってインターネットとイントラネットの両方から隔離され、両者間のバッファとして機能するサーバーを指します。DMZゾーンを区切るファイアウォールには、次の2つの重要な機能があります。

許可されていないトラフィック・タイプをすべてブロックします。
侵入によってプロセスまたはプロセッサが占拠されたときに、侵入の封じ込めを可能にします。

コンポーネントのセキュリティ

各アプリケーション・ソフトウェア・コンポーネントには通常、オペレーティング・システムに適用するものとは別個の、独自のセキュリティ上の考慮事項があります。サイトのセキュリティ要件にあわせて最適に構成する方法を特定するには、各コンポーネントのセキュリティ・ガイドラインを参照してください。

セキュリティの基本的な考慮事項

次は、Oracle Linuxを安全に使用するための基本原則を示します。

ソフトウェアの最新状態の維持

推奨されるセキュリティ実践原則の1つとして、すべてソフトウェア・バージョンおよびパッチを最新に保つことがあげられます。このドキュメントでは、Oracle Linuxリリース7以降のメンテナンス・レベルを想定しています。

詳細は、「ソフトウェア管理の構成および使用」を参照してください

クリティカル・サービスへのネットワーク・アクセスの制限

中間層アプリケーションとデータベースの両方を、ファイアウォールの内側に配置します。さらに、中間層アプリケーションとデータベースが別々のサーバーでホストされている場合は、これらの間にファイアウォールを配置します。ファイアウォールにより、これらのシステムへのアクセスは、必要に応じて監視および制限が可能な既知のネットワーク・ルートに確実に制限されます。代替装置として、ファイアウォール・ルーターは複数の独立したファイアウォールの代わりとなります。

ファイアウォールを使用できない場合は、IPアドレスに基づいてアクセスを制限します。IPアドレスによってデータベース・アクセスを制限すると、しばしばアプリケーションのクライアント/サーバー・プログラムでDHCPクライアントが失敗します。この問題を解決するには、静的IPアドレス、ソフトウェア/ハードウェアVPNまたはWindows Terminal Services(または同等品)の使用を検討してください。

詳細は、「ネットワーク・サービスへのアクセスの構成」を参照してください。

最小権限の原則の順守

最小権限の原則では、ユーザーにはジョブを実行するための最小限の権限を与えるべきであるとしています。特に組織のライフ・サイクルの初期、従業員が少数で作業を迅速に行う必要がある時期に、責任、役割、権限などを不注意に付与すると、システムが大きく開放され不正使用を招きます。ユーザー権限を定期的にレビューして、現在のジョブの責任に対して妥当であることを確認する必要があります。

詳細は、「ユーザーのアカウントおよび権限の確認」を参照してください。

システム・アクティビティの監視

システム・セキュリティは、適切なセキュリティ・プロトコル、正しいシステム構成、システム監視の3つで成りたっています。監査および監査レコードの確認は、この3つめの要件に対処してます。システム内の各コンポーネントには、ある程度の監視機能が備わっています。このドキュメントの監査アドバイスに従って、定期的に監査レコードを監視してください。

詳細は、「監査の構成および使用」を参照してください。

開発者のセキュリティ上の考慮事項

この章では、セキュアなコードを作成するために開発者が従う必要がある原則とガイドラインについて説明します。

セキュアなコーディングのための設計原則

次に、セキュアなコーディングに推奨される代表的な設計原則を示します。

最小権限: プロセスまたはユーザーには、作業の実行に必要な最小限の権限のみを付与する必要があります。ユーザーの権限は、ユーザーのロールに応じて割り当てるべきであり、他の方法で割り当てるべきではありません。最小保護ドメインを作成するには、プロセスやスレッドで必要とするときに権限を割り当て、その後権限を削除します。この原則により、攻撃およびユーザー・エラーによって発生する可能性のある損害を限度内にとどめることができます。
メカニズムの経済性: 設計はシンプルなものにします。間違いが少なくなり、不整合が減少し、コードの理解とデバッグが容易になります。
完全な仲介: リソースへの最初のアクセス試行だけでなく、すべてのアクセス試行をチェックします。たとえば、Linuxではプロセスでファイルを開いた後ではなく、開くときにアクセス権をチェックします。プロセスでファイルを開いている間にファイルの権限が変更された場合は、不正なアクセスが発生する可能性があります。開いているファイルにアクセスされた場合は、必ず権限をチェックすることが理想的です。実際には、アクセス権が最初に取得された状況では、このようなチェックは不要なオーバーヘッドであると見なされます。
オープンな設計: セキュリティは、隠蔽によるセキュリティなどと呼ばれる、コードの設計や実装の秘密性に依存すべきではありません。たとえば、システムのバックドアが開いていることの安全性は、その存在を知っていることの安全性と同じにすぎません。むろん、この原則はパスワードや暗号化キーなどの情報には適用されません。これらの情報は、できるだけ少数の人々の間で共有すべきものです。このため、多くのセキュアな認証スキーマでは、PINコードやパスワードの情報のほかに、生体認証またはハードウェア・トークンやスマート・カードなどの物理的なアーティファクトの所持にも依拠しています。
権限の分離: コードを、各モジュールで特定タスクを実行するための特定の限定された権限セットを必要とする、複数のモジュールに分割します。一般に、注意を要する操作へのアクセス権を付与するには、複数の権限が要求される必要があります。この原則により、職務が確実に分離され、徹底的な防御が可能になります。たとえば、権限のないメイン・スレッドは、タスクを実行するために特権スレッドを生成できます。このため、メイン・スレッドへの攻撃に成功しても、システムへの最小限のアクセス権しか取得できません。
最小共通メカニズム: システムでは、ユーザーとそのアクティビティを互いに分離する必要があります。ユーザーはプロセスやスレッドを共有すべきではなく、ユーザー間で情報チャネルを共有すべきではありません。
フェイルセーフ初期設定: デフォルト・アクションでは、操作へのアクセスを拒否する必要があります。操作を実行する試みが拒否されれば、操作を開始する前と同じセキュリティが確保されます。
アカウンタビリティ: ユーザーが実行を試みたアクションごとに、ユーザーとユーザーの権限を記録します。ファイル・システムが一杯になるのを防ぐために、すべてのログはローテーションおよびアーカイブできる必要があります。
心理的な許容性: セキュリティ・メカニズムはインストール、構成、使用が容易で、ユーザーが回避したいと思わないものにする必要があります。

セキュアなコーディングの一般的なガイドライン

次のコーディング・プラクティスが推奨されます。

タイプ・チェック、長さチェック、バインド・チェックを実行して、入力データがプログラムで必要なデータであることを確認します。入力には、ユーザーが入力するデータの他に、コマンドライン引数および環境変数が含まれます。
インジェクション攻撃で利用される可能性のあるシェル・コマンド、SQL文、XMLおよびHTMLコードなどの構造体が含まれているかどうか、入力データを確認します。
システム・コールおよびライブラリ・ルーチンに対する引数のタイプ、長さ、バインドを確認します。可能な場合は、バッファ・オーバーフローを防ぐライブラリ・ルーチンを使用します。
ファイル名引数にはフルパス名を使用します。あらゆるユーザーが書込み可能なディレクトリのファイルは使用しないでください。また、書き込まれるファイルが実際にはシンボリック・リンクでないことを確認し、既存のファイルが間違って上書きされないようにします。
システム・コールおよびライブラリ・ルーチンから返される値のタイプ、長さ、バインドを確認します。コードが、システム・コールおよびライブラリ関数で設定された、またはこれらから返されたエラー・コードに適切に応答するようにします。
シェル環境の状態を想定しないでください。ユーザー・ファイル作成マスク、シグナル処理、ファイル記述子、現在の作業ディレクトリ、環境変数など、特にPATHやIFSなど、プログラムがシェルから継承した設定を確認します。必要に応じて、設定をリセットします。
有限の値セットをとる変数で、アサーション・チェックを実行します。
権限アクションやエラー条件に関する情報を記録します。エンドユーザーのシステム上で、プログラムがコア・ファイルをダンプできないようにします。
パスワードを画面にエコーしたり、クリア・テキストで転送または保存したりしないでください。パスワードを転送または保存する前に、Salt値と組み合せて、SHA-512などのセキュアな一方向アルゴリズムを使用してハッシュを作成します。
プログラムで疑似番号生成ルーチンを使用する場合、生成する番号が要件を満たすだけ十分にランダムであることを確認します。また、攻撃者が予測できないような、適切な乱数シードを使用する必要があります。詳細は、RFC 4086、『Randomness Requirements for Security』を参照してください。
ホスト・システムでアドレス空間配置のランダム化(ASLR)を有効にすることをお薦めします。この機能は、特定タイプのバッファ・オーバーフロー攻撃を防ぐのに役立つためです。「アドレス空間配置のランダム化」を参照してください。
プログラムをコンパイルしてリンクする際、位置独立実行形式(PIE)機能を使用して位置独立バイナリを生成します。「位置独立実行形式」を参照してください。
chroot()を使用して、プログラムの操作境界をファイル・システム内の指定された場所に制限することを検討してください。
プログラムから、特にsetuidまたはsetgidプログラムからpopen()またはsyscall()をコールしてシェル・コマンドを実行しないでください。

次のガイドラインは、プログラムにsetuidまたはsetgidビットが設定されていて、権限を持たないユーザーのかわりに権限アクションを実行できる場合に適用されます。

シェル・スクリプトでsetuidまたはsetgidビットを設定しないでください。ただし、setuidまたはsetgidなPerlスクリプトを使用する場合、perlはtaintモード(汚染検出モード)で実行され、同等のCコードを使用するよりも安全とされます。詳細は、perlsec(1)マニュアル・ページを参照してください。
setuidまたはsetgidが付与する権限の使用を、その権限を必要とする機能に制限し、その後有効なUIDまたはGIDをユーザーのUIDまたはGIDに戻します。可能な場合は、権限機能は別個の詳細に監視されるスレッドまたはプロセスで実行します。
setuidまたはsetgidプログラムが、PATH環境変数を使用するexeclp()またはexecvp()を使用して子プロセスを実行できないようにします。

ネットワーク・プログラムの一般的なガイドライン

ネットワーク・プログラムには、次のコーディング・プラクティスが推奨されます。

IPアドレスで逆参照を実行して完全修飾ドメイン名を取得し、このドメイン名を使用してIPアドレスを検索します。2つのIPアドレスは同じである必要があります。
過負荷になった場合に、リクエストの処理を停止できるようにして、DoS攻撃からサービスを保護します。
ネットワーク経由の読取りおよび書込みリクエストにタイムアウトを設定します。
ネットワーク経由で受信したデータのコンテンツ、バインド、値およびタイプをチェックして、プログラムで必要とされる内容と合致しないデータは拒否します。
証明書または事前共有キーを使用して、ネットワーク接続のローカルおよびリモート・エンドを認証します。
TLSやSSLなどの定評のあるテクノロジを使用して、ネットワーク接続を介して送信されるデータを暗号化します。
可能な場合は、セキュリティ特性がよく知られている既存のネットワーキング・プロトコルおよびネットワーキング・テクノロジを使用します。
成功および失敗した接続試行、データ受信および送信エラー、サービス状態の変更に関する情報を記録します。

1 システム・セキュリティについて