「データベース暗号化」の必要性と注意すべきポイント：システムインテグレーションとセキュリティ（2）（2/2 ページ）
“SI視点”に立って、システム担当者が考慮すべきセキュリティについて、身近な例を参考に解説する本連載。第2回のテーマは、前回に引き続き「データベースセキュリティ」です。特に、重要なデータを保護するために欠かせない「暗号化」について解説します。
「バックアップ」の暗号化
バックアップを保存する外部メディア（テープ、光学メディア、USBメモリなど）の利用については、技術的な対策やポリシーの策定によって制限するのが基本です。しかし、内部犯行などにより、こうしたセキュリティ対策をかいくぐってデータが窃取されてしまうケースもあります。従って、ディスクやテープに保管したバックアップが盗まれてしまった場合にも、バックアップデータを解析できないようにするために、暗号化が重要になります。
Oracle Databaseの場合、バックアップデータはテープに取得して管理されることが多いようです。テープに保管したバックアップデータの暗号化には、Oracle Advanced Securityライセンスが必要となります。また、他にもRMAN（Recovery Manager）で、バックアップセットの暗号化機能が提供されています。Walletを使った透過的暗号化や、バックアップ／リストア時にパスワードを使うパスワードベースの暗号化、Walletまたはパスワードが使えるデュアルモード暗号化機能が準備されています。
「ネットワーク」の暗号化
アプリケーションとデータベース間の通信は、通常では暗号化されておらず、パケットキャプチャーツールなどで容易に盗聴することができてしまいます。例えば、Oracle Databaseの場合、デフォルトでは従来のPL/SQLパッケージでの暗号化の際にSQL文に埋め込んだ暗号化キーでさえ、平文で流れています。格納データの暗号に加えて、ネットワークの暗号化を行い、クライアントとデータベース間、あるいはデータベースリンク間の盗聴対策を行うことも大切なセキュリティ対策なのです。
「Oracle Database 11gR2」の場合、ネットワークの暗号化はOracle Advanced Securityライセンスがなくても設定することができます。具体的には、サーバ側／クライアント側のsqlnet.oraファイルに、2つのパラメータを設定します。以下にその例を示します。
＜サーバ側＞
SQLNET.ENCRYPTION_SERVER=REQUIRED SQLNET.ENCRYPTION_TYPES_SERVER=(AES_256)
＜クライアント側＞
SQLNET.ENCRYPTION_CLIENT=REQUIRED SQLNET.ENCRYPTION_TYPES_CLIENT=(AES_256)
さて、ここまで、データベースの「格納データ」「バックアップ」「ネットワーク」それぞれの暗号化について、Oracle Databaseを例に紹介しました。ここからは、「データベースセキュリティ編」の締めくくりとして、データベースを構築する際のセキュリティ上のポイントをまとめて紹介します。
製品選定、インストール時の注意点
どの製品でも同じですが、RDBMSはマイナーチェンジを重ねる度に不具合やセキュリティホールが修正され、より完成度が増し、安定稼働できる製品に成長していきます。まずは、可能な限り成熟したバージョンを選定することが大切となります。
Oracle Databaseの場合、いくつかのエディションの中から、必要なエディションのライセンスを購入します。データベース構築時には、誤ったエディションをインストールしないように注意しましょう。ライセンスと異なるエディションをインストールしてしまった場合、ライセンス違反と見なされ、サポートを受けられなくなる場合があります。
また、インストール時には導入するコンポーネントをよく確認し、余計なコンポーネントがインストール対象にならないよう注意しましょう。最近はGUIで簡単にデータベース構築ができる一方で、不要な機能まで導入してしまい、そこがセキュリティホールとなる場合があります。これは、他のRDBMSにおいても同様です。
パッチ適用は構築時に済ませる
次にパッチの適用です。データベース構築のタイミングで、最新のパッチ（Oracle Databaseの場合PSR、PSU）を適用することを検討しましょう。パッチには不具合の修正だけでなく、脆弱（ぜいじゃく）性の修正も含まれています。特別な要件がない限り、最新のパッチを適用するようにしてください。
パッチを適用する際は、適用対象に対して漏れなく実施できていることを確認します。利用するさまざまな機能に対して、個別にパッチが提供されているケースもありますので、個別の機能に対するパッチがリリースされていないか、またそのパッチが他のパッチと競合していないかも事前に確認します。
また、パッチ適用は可能な限り構築のタイミングで済ませましょう。テストフェーズにパッチを適用することになると、テストの手戻りやデータベースを停止するためのスケジュール調整など、非常に多くの工数が追加で必要となってしまいます。カットオーバー後の運用フェーズにおいても、常に最新のパッチ情報を収集し、潜在的な不具合に備えつつ長期的にサポートが受けられるように、適用を検討しましょう。
インフラ構築担当者の役割
データベースインストール後、カットオーバーまでのインフラ構築担当者の（セキュリティ設計上の）役割としては、最低限以下が挙げられます。
- 接続許可クライアントの設定
- ユーザー作成と権限の設定
- 監査証跡（ログ）の設定
- 各層の暗号化の実装
といっても、インフラ担当者のみで決定できないこともあります。特に、アプリケーションが使うユーザーの準備と権限設定については、どのオブジェクトにどのユーザーがアクセスできればよいのかという見極めをインフラ担当者側で行うのは難しいため、アプリケーション開発者との調整が必要となります。またその際、アプリケーション開発者からの要望にセキュリティ上の問題がないかをインフラ側でチェックすることも大切です。
運用フェーズ移行後もユーザーの追加や権限設定の見直し、ログ取得オプションの調整など、アプリケーション開発者から要望が出てくる可能性があります。言うまでもないことですが、システムのセキュリティを高めるためには、インフラ構築担当者とアプリケーション開発者との間で、継続的な協力体制をとることが重要です。
さて、「システムインテグレーションとセキュリティ」連載。第1回、第2回では、「データベースセキュリティ」の観点から、データベースのユーザー管理や監査、暗号化、そしてデータベース構築時のポイントについて説明しました。さまざまな企業資産を蓄えるデータベースは、システムの中でも最も「安全性」や「安定性」が求められる部分です。本稿が、皆さまのシステムの長期安定稼働に少しでも貢献できれば幸いです。
なお、次回以降は、「アプリケーション開発」の視点から、セキュリティ上のポイントについて解説していきます。
著者プロフィール
中野 資久（なかの よしひさ）
2005年からエー・アンド・アイ システム株式会社（現株式会社ラック）で、
インフラ技術者として主にデータベースの設計、構築、保守を担当。
特にOracle製品は、「8i」からのお付き合い。
週末はランニングをしたり、会社仲間と海釣りを楽しむ。
Copyright © ITmedia, Inc. All Rights Reserved.