X

A blog about Oracle Technology Network Japan

  • OCI
    March 23, 2020

オラクルのMaximum Security Architectureで実現するデータベースのセキュリティ

Guest Author

※本記事は、Sean CahillによるOracle’s Maximum Security Architecture for Database Securityを翻訳したものです


セキュリティ制御されるべき領域

御社の機密データを守り、世界中で急増している多数の新しいプライバシー規制に準拠するには、Oracle Databaseの保護が非常に大切です。御社のデータ――たとえば知的財産、財務データ、顧客やスタッフの個人情報、さらにそれらを組み合わせたデータ(この形を取ることが多い)――は、きわめて貴重です。データには価値があるので、盗難や誤用から守る必要があります。

データを本当に守ろうと思ったら、鍵をかけて埋めてしまえばいいのかもしれませんが、そうしたデータは業務での利用を目的としていますから、ユーザーやアプリケーションはそのデータを使用したり、データベースに接続したりしなければなりません。セキュリティ制御によってデータを保護し、御社のポリシーに従ってデータへのアクセスを制限することが必要です。

そのためには、次の3つの手順が求められます。

1.システムを評価して、現在の状態を見極め、修正プランを策定します。

  1. システムは適切に構成されているか。 
  2. パッチは定期的に適用されているか。 
  3. ユーザー権限はどのように管理されているか(付与されている権限は必要最低限か)。
  4. システムにはどのような種類の機密データがどれほど保存されているか。 

Oracle Databaseのお客様であれば、データベースを評価し、改善とリスク軽減の対象となる箇所を特定するのに必要な機能やユーティリティは、ご購入済みのOracle Databaseにあらかじめ用意されています。

2.ポリシーに従っていないデータ・アクセスを検知し、データ・アクセスでの異常を特定します。データベースでは、ほぼすべての動作が繰り返されるため、異常の発見は多くの場合、データ盗難の疑いがあることを最前線で示すものとなります。

3.データベース制御メカニズムを経由していないデータ・アクセス、つまりネットワークを介したトラフィックの傍受、下方にあるデータ・ストレージ層の読取り、データベース・エクスポートやバックアップの誤用を防止します。制御メカニズムを経由したアクセスについては、その状況を見極めて、データにアクセスしたアカウントを特定するだけでなく、不適切なデータ・アクセスをブロックします。

オラクルでは、こうしたセキュリティ制御のそれぞれの目的に合致する、業界屈指の機能を用意しています。オラクルのチームは、制御の目的が実質的に何であれ、御社がふさわしい技術的対策を見つけられるように支援します。

データベースはどのようにして攻撃されるのか

データベースは機密情報の宝庫であり、データを盗みだそうとする人はほぼ必ず、データベース内のデータを悪事の標的にします。この種の攻撃から身を守る方法について考える前に、攻撃がどのように発生するのかを見てみましょう。

データベースは単独で機能しているわけではありません。常に使用されている状態であるため、リスクにさらされることも概して多くなります。データベースには、ユーザーとアプリケーションがアクセスします。多くの場合、テスト用や開発用、さまざまな目的でのステージング用のデータベース・コピーがあります。データベースはストレージ・メディアにデータを保持しつつ、オペレーティング・システムや周辺機器を備えたサーバーで実行されます。管理者がすべてを管理し、大きな権限を与えられているため、ハッカーにとって管理者は狙いどころです。管理者アカウントへの不正アクセスに成功したハッカーは、昇格された権限を手に入れることになり、ほとんどの場合、制御不能でやりたい放題になります。

管理者アカウントを手に入れることはできなくても、エンドユーザー・アカウントを乗っ取ることができる場合が多々あります。与えられている権限は少ないですが、いくらかのデータにはアクセスできたり、SQLインジェクション攻撃によって、目的の管理者アクセスを手に入れるための足がかりとして利用できたりします。

アプリケーションも魅力あるターゲットです。データベースやデータベース・サーバーと比べて公開されている部分が多く、企業のファイアウォールの外から使用できることもあります。

ファイアウォールといえば、社内ネットワークへの侵入に成功した攻撃者が、ネットワークを行き来するデータを攻撃する場合があります。この種の攻撃は、データベースへの直接のアクセスと比べて、はるかに検知しにくくなります。

もう1つのよくある攻撃は、表には出てこないデータファイル、データベース・バックアップ、データベース・エクスポートへの攻撃です。この場合も、攻撃に成功したサイバー犯罪者は、データベースにログインしようとしなくても、データベース全体のデータを盗むことができる可能性があるのです。

上記のようなことが成功しなくても、データベースにパッチ未適用の脆弱性があるかもしれません。多くの場合、そのような脆弱性を悪用するための、自動化された攻撃ツールキットが作成されているものです。

そして、本番用以外のデータベース・コピーについても忘れるわけにはいきません。多くのシステムでは、テスト用および開発用のインスタンスは本番用のクローンですが、セキュリティ対策はほぼなされていません。

では、このような攻撃すべてに立ち向かうにはどうすればよいのか

効果的なデータベース・セキュリティ戦略があれば、複数の異なるセキュリティ制御を採り入れ、そのすべてを連携させることができます。オラクルのセキュリティ制御を、先述したカテゴリ、つまり評価検知防止、そしてデータ主導型セキュリティに分けて説明しましょう。データ主導型セキュリティとは、リレーショナル・データベース内のアプリケーション・データへのアクセスをきめ細かく制御することに主眼を置いた、セキュリティ制御の特別なカテゴリです。

まずは、Oracle Database Security Assessment Tool(DBSATを使用して、データベースの構成を評価し、ベスト・プラクティスからどれほど乖離しているかを調べます。データベースの構成に問題があると、他の制御も効果が薄れる可能性があります。

次に、ユーザーとアプリケーションについて思い出してください。皆がデータベースにログインすることを考えると、Centrally Managed Users(CMU)を使用するのがよいかもしれません。CMUはデータベース機能の1つで、データベースをMicrosoft Active Directoryに接続します。また、Enterprise User Security(EUS)の使用を検討してもよいかもしれません。EUSはデータベースとオラクル独自のディレクトリ・サービスとをつなげるデータベース機能です。いずれの場合も、データベースのユーザーとロールは、データベースから離れてLDAPディレクトリの下に置かれます。

パスワードよりも強力なものを使ってユーザーを認証したいという場合もあるかもしれません。Oracle DatabaseはRadius、Kerberos、PKI証明書による認証をサポートしています。DBSATに話を戻しましょう。ユーザーは誰なのか、どのような権限を持っているかについて知る必要がある場合、DBSATからその情報を得ることができます。

ユーザーが持っている権限に加えて、実際にどの権限を使用しているのかを知りたい場合は、権限分析(PAが役立ちます。権限分析を使用すると、使用されていない権限とロールを特定して、ユーザー・アカウントから削除できるため、アカウントへの不正アクセスがあったときに攻撃対象となり得る領域を狭めることができます。

データベース・クライアントがデータベースにデータを送信し始め、データを取得してレポートを作成したり分析したりするようになると、送受信時のデータの保護についても心配しなければなりません。ここではネットワークの暗号化が有効です。

また、どのような種類のデータがデータベースに格納されているのか知りたい場合は、DBSATを使用して、機密データを探すことができます。

そのデータは最終的にはディスク、バックアップ、エクスポートに保存されるため、そこでデータを攻撃から保護する必要があります。ここは、Oracle Advanced Securityの一部である透過的データ暗号化(TDE)の出番です。TDEはオペレーティング・システム上、ストレージ・デバイス内、バックアップ・ファイルとエクスポート・ファイル内のデータを暗号化します。データを暗号化するとき、つまり1つまたは複数の暗号化鍵があり、鍵を保護し、安全に送信する必要があるときには、Oracle Key Vault(OKVを使用します。OKVはエンタープライズ・アーキテクチャ内のOracle Databaseを認識して、TDE鍵をローテーションしやすくし、古いバックアップやファイルをリストアする必要があるときは、以前に使用された鍵を保護します。

管理者にはデータにアクセスする権限が与えられていることを思い出してください。そのような管理者も保護する必要があります。それには、Oracle Database Vault(DVを使用します。Database Vaultは、データベース管理の役割を、データベース内のデータへのアクセスから切り離します。Database Vaultには不正にアクセスされたアプリケーション・サーバーからの保護機能もあり、アプリケーションのアカウントをロックして、アプリケーションの正常な状態のデータのみにアクセスできるようにします。

アプリケーション外からのデータ・アクセスがある場合、クレジット・カード番号や納税者番号などの機密度の高いデータ列には、保護を追加したいと思うかもしれません。この場合は、Oracle Advanced Securityの一部であるData Redactionを使用して、データベースを離れて送信される間であってもデータを隠すことができます。

さらに、データベースの本番用以外のクローンについては、Oracle Data Masking and Subsetting Packの一部であるData Maskingを使用して、単純に機密データを削除し、セキュリティ上のリスクにならない本物そっくりの“安全な”データに差し替え、アプリケーションの開発とテストはそのまま続けることができます。

データベースを保護するためにさまざまな対策を講じてきましたが、侵入やデータの盗難の疑いを確実に検知することも重要です。そのためには、データベース内に監査を構成し、一元管理された監査ボルトに監査イベントを送信して、分析、レポート作成、アラートの生成を行う必要があります。

ここでは、Oracle Audit Vault and Database Firewallの一部であるDatabase Firewallを使用して、異常やポリシー違反がないか、着信接続要求とSQL文を検証します。必要な場合はさらに一歩進んで、ポリシー違反の動作をファイアウォールによって実際にブロックします。当然ですが、Database FirewallのイベントはAudit Vaultサーバーに送信され、分析、レポート作成、アラート生成に使用されます。

最後になりますが、アプリケーション・ユーザー向けにデータを行や列レベルできめ細かく制御することができます。ここで利用できるオラクルの機能には、Real Application Security(RASOracle Label Securityなど、さまざまなものがあります。このセル・レベルのアクセス制御によって、複数のアプリケーションを開発して、アプリケーション・ユーザーによるデータ・アクセスの認可モデルを統一し、アプリケーション開発に要する時間と労力を減らすことができます。

連携して動作するこれらすべての制御が、Maximum Security Architectureです。これまで紹介したもののほとんどはデータベースの機能であり、Enterprise Editionのお客様であればどなたでも使用できます。追加費用がかかるオプションや製品も一部あります。


 

クラウドでのMaximum Security Architecture

クラウドのすばらしい点の1つは、用意されているそのオプションです。御社のデータベースがOracle Cloudで稼働している場合、Oracle Data Safeも利用できます。Data Safeには、DBSAT、Audit Vault、Data Maskingと同等の、Oracle Databaseを保護するための複数の機能があります。

Database Vaultや透過的データ暗号化のようなオプションもクラウドで提供されており、ほとんどのクラウド・サービス(Oracle Autonomous Databaseなど)は、追加料金不要でサブスクリプションに含まれています。多くの場合、自動で有効になり、構成されます。

クラウドでMaximum Security Architectureを実装するほうが簡単だということです。

忘れるべきでないのは、大半のサイバー攻撃の目的は、御社のもっとも価値ある資産、つまりデータを入手することです。その資産を保護するために、Maximum Security Architectureをガイドとして使用してください。

Maximum Security Architectureについての詳しい情報は、Oracle Database SecurityのWebページをご覧になるか、オラクルの電子書籍をダウンロードしてください。

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.