X

クラウド・セキュリティに関する考え方、製品情報、事例、セミナー (データベースセキュリティ・CASB・IDaaS・WAF・DDoSなど)

Recent Posts

Oracle Cloud Infrastructure Web Application Firewallのご紹介

原文はこちら https://blogs.oracle.com/cloud-infrastructure/introducing-the-oci-waf Oracle Cloud Infrastructure上のワークロード、また、マルチクラウドのWebアプリケーション向けのOracle Cloud Infrastructure Web Application Firewall (WAF)をリリースしたことをご案内します。Oracle Cloud Infrastructure WAFは、インターネットに面するWebアプリケーションを悪意のサイバー攻撃やスクレイピング・ボットから防御するための、エンタープライズグレードでクラウドベースのセキュリティソリューションです。2018年のOracleとKPMGによるクラウド脅威レポートによれば、回答者の51%が、不正アクセスから組織の機密データを守る方法としてWebアプリケーションファイアウォールが最も優先度が高いと回答しています。 今日では、Webアプリケーションはデジタルビジネスの中核を成していますが、サイトに侵入しようという悪意を持った者によるサイバー攻撃の脅威に恒常的にさらされています。もし侵入を許せば、データを盗まれたり、不正なソフトウェアをサイトを訪れるお客様に広められてしまったり、評判を傷つけられたりしてしまいます。なのでクラウドにワークロードを移行しようとしているすべての企業にとってセキュリティが一番の関心事であること、また、Webアプリケーションファイアウォールが今日のデジタルビジネスにとって絶対必要だとみなされることに不思議はありません。Webアプリケーションファイアウォールなしでは、多くの企業は重要なアプリケーションやデータ、サービスをクラウドに移行しようとも考えないでしょう。Oracle Cloud Infrastructure WAFは、Oracle Cloud Infrastructure、オンプレミス、マルチクラウドのワークロードに安全と安心を提供します。 WAFサービスはサイバー攻撃から多層的なアプローチでWebアプリケーションを守ります。今回のリリースでは、Open Web Access Security Project(OWASP)のものや特定のアプリケーション、特定の規制準拠のためのものなど、250以上の定義済みルールが含まれています。WAFにはまた、Webroot BrightCloud®を含む複数のソースを統合した脅威インテリジェンスも提供します。管理者はアクセス制御を地理、IPアドレスのホワイトリスト/ブラックリスト、HTTP URLやヘッダの特徴にもとづいて行うことができます。ボット対策にはJavaScript受け入れ、CAPTCHAやデバイス・フィンガープリント、ヒューマンインタラクション・アルゴリズムなどのより高度なチャレンジを提供しています。WAFサービスにアプリケーションを登録しておくことで、レイヤー7 分散型サービス拒否(DDoS)攻撃から守ります。 WAFの仕組み Oracle Cloud Infrastructure WAFはリバースプロキシとして動作し、通信フローやリクエストがもとのWebアプリケーションに到達する前に監査をします。また、Webアプリケーションサーバからエンドユーザーへのいずれのリクエストも監査します。 この強力なサービスによって、アプリケーションサーバからのデータ漏えいを制御し、外部の脅威からサーバを守ることができるようになります。 WAFの統合 Oracle Cloud Infrastructure WAFは他のOracle Cloud Infrastructureのアプリケーション、サービスとコンソール上で密に統合されており、セットアップと管理が簡単にできます。たとえば: WAFのポリシーにタグを付け、コストを追跡する ID管理・アクセス制御(IAM)を用いてWAF管理へのアクセス制御を行う 監査サービスにWAFの変更を記録 WAFはEdgeサービス・メニューの配下にあります。受動検知用の定義済みルールを有効にしたり、Webアプリケーションのリバースプロキシ―として個別のルールでWAFにブロックを行わせたりできます。 WAFを通ったトラフィックのログはコンソール上で分析することもできますし、エンタープライズSIEMに引き入れることもできます。 コンソール上での統合に加えて、WAFでは堅固なRESTful APIの利用も可能です。これには複数の言語のSDK、CLIおよびTerraformが含まれます。 主要なユースケース 以下はWebアプリケーションファイアウォールのユースケースの一部です: サイバー攻撃からの防御:Oracle Cloud Infrastructure WAFはクラウドベースで提供され、OWASPのルールセットに加え、250のルールセットをサポートしています。こうしたルールを使い、重要なWebアプリケーションを悪意のサイバー攻撃から守ります。インカミングリクエストはこれらのルールにより攻撃ペイロードを含んでいないか評価されます。リクエストが攻撃であると判断された場合、WAFはそのリクエストをブロックするか、またはアラートを挙げます。こうした攻撃は多種多様で、SQLインジェクションやクロスサイトスクリプティング、HTMLインジェクションなどの脅威を含んでいますが、いずれもWAFルールで検知、ブロックが可能です。 データプライバシー標準のためのアクセス制御:アクセス制御を用いて重要なWebアプリケーション、データやサービスへのアクセスをコントロールします。例えば、リージョンベースのアクセス制御はEUのGDPRコンプライアンス要件に適合します。しばしば、あるサービスの提供をGDPRに則った特定の地域に限る必要があります。リージョンベースのアクセス制御を用いてユーザーアクセスをある地域に限定し、たとえばアメリカにあるサーバーから情報を取得できないようにする、といったことが可能です。あるいは、特定の国からのアプリケーションアクセスを完全にブロックするといったこともできます。たとえば、アジアの国々とのビジネスを行っていない場合に、それらの国々からのアクセスをブロックする、といったことも出来ます。 既存の管理システムとの統合:RESTful APIは、WAFへの完全なシステム間インターフェースを提供します。すでにバックエンドの管理システムを保持しており、コンソールは不要なので、WAFを既存管理システムと直接統合したいというときに理想的です。 ボット対策:インターネット上では、ボットによるトラフィックは人間によるそれよりも多くなっています。ボットの大半は悪意のないものですが、しかしそれゆえ単にボットを全てブロックしてしまうということもできません。JavaScriptチャレンジ、CAPTCHAチャレンジ、ホワイトリスト機能をWAFルールセットと併せて用いることで、良性ボットをとおして悪性ボットをブロックすることが可能です。 ハイブリッド・マルチクラウドの保護:多くのクラウドプロバイダがWebアプリケーションファイアウォールの防御を自身のクラウド上のアプリケーションのみに制限しています。Oracle Cloud Infrastructure WAFではそのようなことはありません。Oracle Cloud Infrastructure上のワークロードに加え、WAFはオンプレミスとマルチクラウド環境も防御します。Oracle Cloud Infrastructureへの移行にあたり、単一のWebアプリケーションファイアウォールでいずれの環境も防御できるというのは非常に重要なことです。移行のそれぞれのフェーズ―クラウド上でのテスト、移行とカットオーバーでWAFがあなたの環境を防御します。 まとめ Oracle Cloud Infrastructure WAFは、もはやVPNや専用線の必要なしにインターネットに接するWebアプリケーションを実現するための鍵となります。Oracle Cloud Infrastructure WAFについての詳細は、こちらのWebサイトまで。 関連情報 どのように洗練された行動分析がボット攻撃を阻止するか 多層セキュリティによるレイヤ7 DDoS攻撃の防止

原文はこちらhttps://blogs.oracle.com/cloud-infrastructure/introducing-the-oci-waf Oracle Cloud Infrastructure上のワークロード、また、マルチクラウドのWebアプリケーション向けのOracle Cloud Infrastructure Web Application Firewall (WAF)をリリースし...

セキュリティ全般

多層セキュリティによるレイヤ7 DDoS攻撃の防止

原文はこちら (著者 : Laurent Gil) https://blogs.oracle.com/cloud-infrastructure/stop-layer-7-ddos-attacks-with-multilayered-security 従来型のサイバー攻撃はますます自動化されており、これは特に分散型サービス拒否(DDoS)攻撃および同様の攻撃があてはまります。これらの攻撃への対応も自動化する必要があります。 大手テクノロジインフラストラクチャ企業が使用する重要なSaaSのWebサイトを運営する組織に対するボットネット主導のDDoS攻撃を防ぐために、Oracle Cloud Infrastructure Web Application Firewall (WAF)は自動化と多層での検出と緩和アプローチを使用しました。 Oracle Cloud Infrastructureのヘテロジニアス・エッジ・ネットワークは、世界中に分散した大規模アプリケーションの拠点と超大容量のDDoS攻撃対策スクラビングセンターの組み合わせであり、このレイヤ7 DDoS攻撃を軽減するうえで重要な役割を果たしました。攻撃が特定のしきい値に達すると、DDoS攻撃対策スクラビングセンターが開始します。 攻撃の分析 アプリケーション層(レイヤ7)のDDoS攻撃は、大量のゴミトラフィックをWebサイトに送信するためにボット・ネットワーク(ボットネット)を使用します。このトラフィックの唯一の目的は、Webサーバーにリクエストをあふれさせることです。通常、特にレイヤ7 DDoS攻撃の場合、ボットは人間の活動をシミュレートすることによってサイトにアクセスしようとします。時にはコマンドラインツールのApache Benchmarkと同じくらい簡単なものもあります。この場合、人が実際のWebブラウザを介してサイトにアクセスする動作とは異なります。 レイヤ7 DDoS攻撃の目的は、アプリケーションサーバに大量アクセスを行い、アプリケーションの利用を不可にする、または少なくともその応答時間を悪化させることです。この種の攻撃は、他の悪意のある洗練された攻撃を隠し、より大きなイベントの前段としてアプリケーション防御機能をテストするために実行されることがあります。 この攻撃では、通常1秒あたり50のリクエストを受信するWebサイトが、数分間で1秒あたり2,800を超えるリクエストを受信しました。これは、数分で100万要求に達し、約150 Mbpsのトラフィックとなり、通常より2桁大きくなりました。 全体で100万件のリクエストと、秒間2,800件のリクエストは大規模ではありません。Oracle Cloud Infrastructure WAFは秒間50万件以上のHTTPリクエストを生成する攻撃から顧客を保護した実績もあります。しかし、多くの場合、サイトをダウンさせるのに十分な量です。 次のグラフは、通常の日(10月31日、攻撃の前日)にサイトに送信された1秒あたりのリクエスト数を示しています。 次のグラフは、攻撃当日の1秒あたりのリクエスト数を示しています。 全体としては、ボットネットは数分以内に100万のリクエストを行うために数カ国に分散したIPアドレスを使用しました。そのような攻撃は、サイトを破壊するのに十分すぎるほどだったでしょう。 攻撃への対処策 この攻撃は、JavaScriptチャレンジと呼ばれる防御メカニズムを使用して、Oracle Cloud Infrastructure WAFのボット管理機能によって緩和されました。設計上、セキュリティプラットフォームは攻撃を自動的に確認すると、防御メカニズムを自動的に有効にします。 セキュリティプラットフォームは、Oracle Cloud Infrastructureの大規模なエッジネットワークを使用して、リバースプロキシでエンドユーザーからの各リクエストに軽量なJavaScriptを挿入します。JavaScriptは、エンドユーザーのブラウザに完全なJavaScriptエンジンが搭載されているか調べて確認します。正常なブラウザからのトラフィックを許可しながら、DDoSを専門とするボットネットの典型である不完全なブラウザからのトラフィックを排除します。 次の図は、1,071,261件のリクエスト(攻撃の99.9パーセント)がOracle Cloud Infrastructure WAFによって自動的に検出され軽減されたことを示しています。   Oracle Cloud Infrastructure WAFには、リアルタイムの行動分析など、ボットトラフィックを識別およびブロックするための他の高度な機能もあります。  自動化の重要性 この攻撃からサイトを保護するためには、自動化が重要でした。ボットマネージャーがリクエストの急増に気付いたとき、ボットマネージャーは自動的に対策防御の1つ(JavaScriptチャレンジ)を選択して有効化、チャレンジに失敗したリクエストをブロックしました。セキュリティオペレーションセンター(SOC)のアナリストは攻撃を阻止するために何もする必要はありませんでした。攻撃は深夜に行われたため、良いニュースです。 自動化しなければ、リクエストの数が劇的かつ急速に増えたため、サイトはダウンしていました。1秒間に平均50件のリクエストのために構築された典型的なサイトは、1秒間に2,800件のリクエストに耐えることができません。 さらに、サイトが停止した場合、ボットネットを特定するのは困難でした。SOCアナリストはログを見なければならなかったでしょうが、彼らはトラフィックの大幅な増加以外に何も悪いことは見ていなかったでしょう。彼らはそれがおそらくボットネットであることを分かりますが、どのトラフィックがボットから来たのか、そしてどのトラフィックが正当であるのか、またはそれをブロックする方法を遡って特定する方法はありません。 攻撃が数個のボットのみから行われた場合、1秒あたり2,3件を超えるリクエストを行うアドレスをブロックする、IPレート制限が効果的な対策となります。しかし、この攻撃では、ボットネットは大量のボットとIPアドレスを使用し、個々のアドレスからのリクエストの数は非常に少なくなっていました。 ボットネットのIPアドレスからの位置情報の分布を注意してみてください。 多層のアプローチ 攻撃を確認するのにかかる時間は、しばしば少しの攻撃漏れをもたらすことに注意することは重要です。この攻撃では、100万件のうち約6万件のリクエストがボットマネージャーによってブロックされませんでした。 これは仕様によるものです。ボットマネージャーは、攻撃が確認されたときにのみ機能します。つまり、自動的にトラフィックのブロックを開始する前に、立て続けに失敗した多くのリクエストが待機しています。 これら6万件のリクエストはすべて、Oracle Cloud Infrastructureのエッジネットワークからのボットマネージャーのキャッシングレイヤによって処理されました。リクエストはどれもオリジンに送信されませんでした。その結果、オリジンサーバーは攻撃の影響を受けず、会社のWeb資産も影響を受けませんでした。 Oracle Cloud Infrastructure WAFは、以下の2つの理由で顧客のWebサイトのコンテンツをキャッシュします。 パフォーマンスの向上:ページの内容をすでに分かっているのであれば、オリジンサーバーにそれを要求する必要はありません。 攻撃からの保護: キャッシングはセキュリティチームによって見落とされがちですが、レイヤ7 DDoS保護の重要な要素です。 レイヤ7 DDoS攻撃は多発しています。攻撃者にとって、それらは多くの目的を果たすことができます。重要な期間にeコマースの競争を排除したり、サイトの所有者を強要したり、場合によってはより深刻な攻撃を行うためのスモークスクリーンとして利用します。 統一された分散プラットフォームからもたらされる連鎖的なチャレンジを使用することで、レイヤ7 DDoS攻撃を軽減することが可能です。サイトの所有者は、オリジンリソースが影響を受けてサイトがオフラインになる前に、ボットネットトラフィックがエッジで阻止されるようにすることができます。

原文はこちら (著者 : Laurent Gil)https://blogs.oracle.com/cloud-infrastructure/stop-layer-7-ddos-attacks-with-multilayered-security 従来型のサイバー攻撃はますます自動化されており、これは特に分散型サービス拒否(DDoS)攻撃および同様の攻撃があてはまります。これらの攻撃への対応も自動化...

セキュリティ全般

どのように洗練された行動分析がボット攻撃を阻止するか

原文はこちら (著者 : Laurent Gil) https://blogs.oracle.com/cloud-infrastructure/how-sophisticated-behavioral-analytics-thwarted-a-bot-attack-v2 Oracle Cloud Infrastructure Web Application Firewall(WAF)は、数か月前に主要なECサイトへの悪意のあるボット攻撃を特定し、軽減しました。 この記事では、洗練された行動分析によって攻撃をどのように阻止したか、それが core-to-edge セキュリティ戦略の重要な要素である理由を紹介します。 攻撃手法 EC業界では一般的であるように、顧客のWebサイトは2つの要素に分かれています。 パンフレットウェアサイト:購入商品の選択を含むホームページ コマースエンジン:実際のトランザクションが実行されるバックエンド固有のもので、ユーザーID管理とペイメントゲートウェイが含まれます。 パンフレットウェアサイトとコマースサイトの両方が同じドメインで、顧客は2つのコンポーネントの違いは意識しません。 この場合、両方のコンポーネントは、さまざまな国やタイムゾーンの別々のクラウド環境がホストされています。 顧客のパンフレットウェアサイトの一般的なトラフィックパターンは、夜間はほとんどトラフィックがなく、顧客が利用する日中はトラフィックが増加します。攻撃を受けた当日は、一般的なトラフィックパターンに比べて、昼間のわずかなトラフィックの増加が見られました。 トラフィックの急上昇は、48時間のトラフィックにわたって、サイトのパンフレットウェアコンポーネントにはっきりと表示されます。 コマースサイトでは、疑わしいトラフィックが急増しました。1秒あたりのリクエストの規模を見てください。コマースサイトのほうがパンフレットウェアサイトより2桁高いのです。 通常は、顧客のアプリケーションは約8000万から9000万のリクエストを受けています。この攻撃は非常に洗練され、分散されたボットネットによって、約1000万件の追加リクエストが行われました。Oracle Cloud Infrastructure WAF によって、ボットネットは自動的に識別し、悪意のあるものとして分類してブロックしました  。ボットネットの主な目的は、一時的に在庫保有をすることによって人為的に価格を引き上げることで、それにより競合他社のサイトでの顧客の購入を促しました。 アタック検出 Oracle Cloud Infrastructure WAFは、オラクルの大容量のエッジ・ネットワークを利用してリアルタイムでトラフィックを分析します。これは、トラフィックをクライアントのWebプロパティにプロキシするグローバルに分散されたPOP(Point of Presence)です。 不審なアクティビティが検出されると、WAFのボット管理機能は自動的に分類して、人以外の流入トラフィックをブロックしようとする対策を実行します。ボットネットの高度さに応じて、アプリケーションセキュリティエンジンが自動的に対策を選択します。 Oracle Cloud Infrastructure WAFは、ボットトラフィックの急増を自動的に識別してブロックしました。 攻撃の洗練度とプラットフォームが選択した対抗策は注目に値します。 多くの場合、大規模なボットネットは脅威インテリジェンス層(ボットネットのIPアドレスが既知であり、組織のコンソーシアムによってブラックリストに登録されている場合)またはJavaScript防御層(トラフィック要求に一般的なインターネットブラウザの典型的なJavaScriptエンジンがない場合、ボットとして分類)によって識別されます。 この場合、Oracle Cloud Infrastructure WAFは自動的に起動し、デバイス・フィンガープリント・チャレンジとヒューマン・インタラクション・チャレンジの2つの高度な対策を使用して、疑わしい悪意のあるボットを識別、およびブロックしました。次の図は、これら2つの対策を使用して悪意のあるトラフィック全体が軽減されたことを示しています。 この例では、IPブラックリスト、WAFルール、JavaScriptチャレンジなどの従来のボット管理技術を使用してボットネットをブロックすることは出来ませんでした。 洗練された自動ボット管理 この攻撃でボットの大部分をブロックしたヒューマン・インタラクション・チャレンジは、正当な訪問者の行動分析に基づいて各Webアプリケーションの通常の利用パターンを特定し、標準的な利用行動、アクティビティ、頻度から逸脱するボットにカスタマイズ可能なセキュリティ保護体制を提供します。これが、人工知能のサブセットである機械学習が役立つところです。 ヒューマン・インタラクション・チャレンジが最大限の可能性を発揮するためには、学習モデルを取り入れる必要があります。このモデルは、既知の署名、リクエストヘッダー、共通のIPアドレス、リクエスト言語、およびその他の要素を組み合わせて、正当なユーザーの行動のプロファイルを作成します。トラフィックがこれらの既知の動作パターンに違反すると、トラフィックはチャレンジフラグが立てられ、ブロックされます。 デバイス・フィンガープリント・チャレンジは、50を超える属性に基づいて、仮想ブラウザと実際のブラウザの両方のハッシュ署名を生成します。これらの独自のシグネチャは、リアルタイムの相関関係を悪用して悪意のあるボットを識別してブロックします。 ボットネットは何をしているか ボットがカート詰めとして知られている攻撃を実行していたのではないかと思います。この場合、ボットはアイテムを予約していましたが、購入は完了していませんでした。これにより、システムはこれらの商品を支払い保留中の在庫から除外し、他の商品の価格を引き上げました。在庫が限られているために商品が売り切れたり、価格が高すぎたりするため、ユーザーはサイトを離れていました。 次の図に示すように、ボットネットはさまざまなIPアドレスと原産国を使用していました。画像はトラフィックあたりの上位国を示しています。ボットネットは通常、さまざまな場所によく配布されていることに注意してください。これは、この攻撃を実行した侵入先のコンピュータが拡散していることを意味します。これはハッキングチーム自体の地理的位置を示すものではありません。 場合によっては、死後のボットの活動の痕跡を見つけることができます。以下は、侵入されたボットネットホストの1つで見つけたファイルの例です。これは、動的な価格設定が誤ったトラフィックによってどのように操作される可能性があるかを示しているようです。 結論 ボット技術がますます洗練されるにつれて、それを止めるために使用される技術も同様に進歩しなければなりません。基本的なボット保護は依然として必要ですが、サイバーセキュリティの将来には、新たな脅威に対する完全な保護のための自動化が組み込まれている必要があります。セキュリティチームが、疑わしい活動の最も早い兆候が検出されたときに防御を有効にするのには、スマートなシステムとプロセスを選択して利用することが重要です。 Oracle Cloud Infrastructureの最先端のセキュリティ戦略は、さまざまな外部および内部の脅威からユーザーと組織を保護し、イベントを共通管理し、アラート、および緩和策の統合を組み込みます。多くの場合、今回紹介したケースのように、攻撃は何百万ものボット要求を行います。攻撃をすばやく識別して対処できるように、瞬時に大容量を動員する必要があります。オラクルの最先端のコンピューティングとインフラストラクチャのキャパシティは、非常にスケーラブルでほぼ無限です。 今回のケーススタディでは、顧客アプリケーションは4,500マイル離れた国の2つの異なるクラウドプロバイダによってホストされています。企業は、オンプレミスのレガシーシステムとそのプライベートクラウドと組み合わせて、複数のクラウドプロバイダーを使用することが増えています。したがって、Oracle Cloud Infrastructure WAFは、アプリケーションがホストされている場所(Oracle Cloud、Amazon Web Service、Microsoft Azure、Google Cloud Platformなど)およびそれらのネットワーク配信メカニズム(コンテンツ配信など)とは独立して機能するように設計されています。 この設計はセキュリティとパフォーマンスにとって特に重要です。なぜなら、1つのプラットフォームがすべてのイベントと監視に関するグローバルなビューを提供し、すべてのアプリケーションに対する独自の保護層として機能するからです。

原文はこちら (著者 : Laurent Gil)https://blogs.oracle.com/cloud-infrastructure/how-sophisticated-behavioral-analytics-thwarted-a-bot-attack-v2 Oracle Cloud Infrastructure Web...

セキュリティ全般

【3/1開催】 Cloud Security Day 世界のトレンドと国内先進事例

3/1(金)に、クラウドセキュリティにおける2019年の最新トレンドと海外との比較から日本に求められる課題や最新テクノロジーを解説するとともに、急成長を遂げているアウトソーシング様がクラウドの活用を進める中で、ガバナンスやセキュリティを強化するためにどのようなアプローチをとってきたのかをご紹介いただき、サイバーセキュリティ対策の在り方を提示する、セミナーを開催致します。 ご都合のつく方は、是非ご参加ください。 ◇ イベント開催概要 ◇ 日時:3月1日(金) 14:30 - 17:00 (受付開始 14:00-) 会場:日本オラクル株式会社 参加費:無料 ※事前登録制 詳細内容/ご参加のお申込み => こちら ◇ アジェンダ ◇  アウトソーシングの考える、クラウド活用と保護のあるべき姿とは 株式会社アウトソーシング 経営管理本部 総務部 部長 グループCSV推進 眞鍋 謹志 様   出遅れる日本企業のクラウドセキュリティ グローバル比較で見えてきた改善のポイント KPMGコンサルティング株式会社 パートナー 澤田 智輝 様   クラウド時代のサイバーセキュリティ対策 日本オラクル クラウドプラットフォーム戦略統括 ビジネス推進本部 大澤 清吾 [関連情報] オラクルのクラウドセキュリティソリューション (CASB / IDaaS / SIEM / UEBA)

3/1(金)に、クラウドセキュリティにおける2019年の最新トレンドと海外との比較から日本に求められる課題や最新テクノロジーを解説するとともに、急成長を遂げているアウトソーシング様がクラウドの活用を進める中で、ガバナンスやセキュリティを強化するためにどのようなアプローチをとってきたのかをご紹介いただき、サイバーセキュリティ対策の在り方を提示する、セミナーを開催致します。 ご都合のつく方は、是非ご参加...

セキュリティ全般

Oracle OpenWorld 開幕

10月22日からOracle Open World が開幕しました。 今年も多くの見どころのあるセッションが提供させて頂きます。 セキュリティに関しても様々なアップデートが予定されていますので、随時紹介します。 基調講演の様子は、Liveキャストで視聴可能です。 https://www.oracle.com/openworld/live/index.html また見られなかった方は、基調講演のオンデマンド動画が、以下で随時公開されますので、こちらのサイトもご確認ください。 https://www.oracle.com/openworld/on-demand.html 既に、初日の基調講演の記事が以下のサイトで掲載されています。 [速報]オラクル、2019年に東京と大阪にOracle Cloudの最新データセンターを開設へ。Oracle OpenWorld 2018 オラクルがクラウドインフラを刷新、「セキュリティを最優先した」とエリソン会長 オラクル、SaaS製品群にAI機能を拡充--モデル駆動型で業務を自動化

10月22日からOracle Open World が開幕しました。 今年も多くの見どころのあるセッションが提供させて頂きます。 セキュリティに関しても様々なアップデートが予定されていますので、随時紹介します。 基調講演の様子は、Liveキャストで視聴可能です。 https://www.oracle.com/openworld/live/index.html また見られなかった方は、基調講演のオンデマンド...

データベースセキュリティ

[10/30開催] DBSC秋のセミナー ~ サマータイム議論で考える情報システムにおける時刻の持ち方 ~

10/30 (火) にデータベース・セキュリティ・コンソーシアムの秋セミナーが開催されます。 サマータイム導入が検討されているというニュースが話題となりました。本セミナーでは、サマータイム導入や2038年問題などで考えられる、情報システムにおける時刻の持ち方やセキュリティの課題について、DBSC副会長の上原哲太郎 先生による基調講演 及び パネルディスカッションにて考察します。 日本オラクルからは、企業企業によるソリューション紹介で登壇させて頂きます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━        <データベース・セキュリティ・コンソーシアム(DBSC)主催>                                DBSC秋のセミナー    ~ サマータイム議論で考える情報システムにおける時刻の持ち方 ~   [日時] 2018年10月30日(火) 13:00~17:00   [URL]  http://www.db-security.org/seminar/20181030.html   [会場] 日本オラクル株式会社「13Fセミナールーム」  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2020年東京オリンピックの暑さ対策として、サマータイム導入が検討されているというニュースが、今夏に話題となりました。過去にも何度か導入が検討されては見送られた理由には様々あるようですが、本セミナーでは、サマータイム導入や2038年問題などで考えられる、情報システムにおける時刻の持ち方やセキュリティの課題について、基調講演 及び パネルディスカッションにて考察します。  DBSC会員企業だけではなく、一般の方もご参加いただけますので、ぜひお申込みください。どうぞよろしくお願いいたします。  ※本イベントご参加で、(ISC)2認定資格保持者様のCPEクレジット(3ポイント)が取得可能です。 ///// セミナー概要 //////////////////////////////////////////////////////// ■日程 / 2018年10月30日(火) 13:00~17:00 ■参加費 / 無料 ■定員 / 70名 ■会場 / 日本オラクル株式会社「13Fセミナールーム」             【所在地】東京都港区北青山2-5-8 オラクル青山センター             【最寄駅】「外苑前」:外苑前駅 4B出口より接続             「青山一丁目駅」:地下鉄銀座線・半蔵門線・大江戸線 徒歩9分 ■内容 /  13:00~13:10 開会挨拶 DBSC会長:安田浩 氏 [東京電機大学 学長] 13:10~14:10 基調講演「情報システムにおける時間の表現とデータベース」 DBSC副会長:上原哲太郎 氏 [立命館大学 情報理工学部 教授] この夏にわかに沸き起こったサマータイム騒動は情報システムにおける時刻の 取り扱いの難しさを改めて浮き彫りにした。そこでここでは情報システムにおける 時間の表現がどうなっており、それがデータベースでどのように実装されているか についてまとめておきたい。特に永続性が求められるデータベースにおいて、 時刻の表現が2038年など特定の時期に大きな問題を引き起こしかねないことを指摘する。 14:10~14:40 DBSC講演「『DBA1,000人に聞きました』アンケート調査報告」 DBSC運営委員:北野晴人 氏 [情報セキュリティ大学院大学] 14:40~15:10 DBSC会員企業によるソリューション紹介  日本オラクル株式会社 調整中 15:10~15:25 休憩 15:25~16:55 パネルディスカッション パネラー:安田浩 氏、上原哲太郎 氏、北野晴人 氏 モデレータ:西本逸郎 氏 16:55~17:00 閉会挨拶 DBSC事務局長 西本逸郎 氏 [株式会社ラック] ~ 内容は予告無く変更される場合もございますことご了承ください ~   ※ ご参考:過去の実施イベント 明日登壇します。DBSC秋の臨時セミナー ~「ランサムウエアとDBセキュリティ」~ [2/28開催] DBSC早春セミナー ~ データ主導社会におけるデータベースセキュリティ ~ [5/30開催] 第14回DBSC春のセミナー ~ データの越境流通についての世界の動向 ~  

10/30 (火) にデータベース・セキュリティ・コンソーシアムの秋セミナーが開催されます。 サマータイム導入が検討されているというニュースが話題となりました。本セミナーでは、サマータイム導入や2038年問題などで考えられる、情報システムにおける時刻の持ち方やセキュリティの課題について、DBSC副会長の上原哲太郎 先生による基調講演 及び パネルディスカッションにて考察します。 日本オラクルからは、企...

セキュリティ全般

[10/19開催] 来たるべきクラウドファースト時代に求められるサイバーセキュリティー対策 ~世界のトレンドと国内先進事例のご紹介

10/19(金)に KPMGコンサルティング様と共催でイベントを開催します。 本イベントでは、9/19に発表したオラクルとKPMG、クラウドセキュリティに関する意識調査をふまえ、クラウドセキュリティにおけるトレンドと最新テクノロジーを解説するとともに、リクルート様に先進取り組み事例をご紹介いただき、クラウドファースト時代に求められるサイバーセキュリティー対策の在り方を提示します。 詳細は以下になります。ご参加お待ちしております。 ◇ イベント開催概要 ◇ 日時:10月19日(金)15:00-17:00(14:30 受付開始) 会場:大手町フィナンシャルシティ サウスタワー 20階セミナールーム S4 主催:KPMGコンサルティング株式会社、日本オラクル株式会社 受講料:無料 定員:40名 詳細内容/ご参加のお申込み => こちら プログラム  -------------------------- 15:00~15:40 グローバルトレンドに基づくクラウドセキュリティ対策の高度化 KPMGコンサルティング株式会社 畠山 誠氏 15:40~16:10 あなたはどうクラウドを守る?AI・自動化を使った、見えない脅威との戦い方 日本オラクル株式会社 大澤 清吾 16:10~16:40 リクルートにおけるクラウドセキュリティ ~リスクアセスメントと外部攻撃監視の現場から~ 株式会社リクルートテクノロジーズ 高橋 正人 氏、安東 美穂 氏 --------------------------

10/19(金)に KPMGコンサルティング様と共催でイベントを開催します。 本イベントでは、9/19に発表したオラクルとKPMG、クラウドセキュリティに関する意識調査をふまえ、クラウドセキュリティにおけるトレンドと最新テクノロジーを解説するとともに、リクルート様に先進取り組み事例をご紹介いただき、クラウドファースト時代に求められるサイバーセキュリティー対策の在り方を提示します。 詳細は以下になります。...

[9/19 発表] オラクルとKPMG、クラウドセキュリティに関する意識調査を実施

本日、KPMGコンサルティングと日本オラクルは、オラクル・コーポレーションとKPMGが共同で実施したクラウドセキュリティに関する意識調査をまとめたレポート「オラクルとKPMGによるクラウドの脅威レポート 2018年」(日本語版)を発行し、そのプレスリリースを行いました。 ■ プレスリリース オラクルとKPMG、クラウドセキュリティに関する意識調査を実施 9割がクラウドに機密性の高いデータを格納する一方で、82%がセキュリティポリシーに従うかどうかを懸念、4割はクラウド上のセキュリティインシデントの検出・対処を最優先課題と回答 日本オラクル KPMGコンサルティング ■ 本レポートのポイント 90%:自社がクラウド上に保管しているデータの半数以上が機密性の高いデータであると回答 83%:自社のオンプレミス環境と同等あるいはより安全であると考えている 60%:自社の持つデータの4分の1以上がクラウド上に保管されている 82%:自社の従業員がセキュリティポリシーに従うかどうかを懸念している 38%:サイバーセキュリティの最優先課題として、クラウド上のセキュリティインシデントの検出・対処 84%:高度な攻撃者から効果的に防御するために、より多くの自動化を活用するとコミット ■ 資料ダウンロード ■ 本レポートを解説するイベント [10/19開催] 来たるべきクラウドファースト時代に求められるサイバーセキュリティー対策 ~世界のトレンドと国内先進事例のご紹介   ■ 関連記事 オラクルのクラウドセキュリティソリューション (CASB / IDaaS / SIEM / UEBA) 【記事紹介】 セキュリティ脅威調査:62%の企業が、クラウドのセキュリティの方が優れていると回答   

本日、KPMGコンサルティングと日本オラクルは、オラクル・コーポレーションとKPMGが共同で実施したクラウドセキュリティに関する意識調査をまとめたレポート「オラクルとKPMGによるクラウドの脅威レポート 2018年」(日本語版)を発行し、そのプレスリリースを行いました。 ■ プレスリリースオラクルとKPMG、クラウドセキュリティに関する意識調査を実施9割がクラウドに機密性の高いデータを格...

セキュリティ全般

[7/27開催] Oracle Innovation Summit Tokyo 2018

7/27(金)に Oracle Innovation Summit Tokyo 2018 が、開催されます。 本イベントでは、世界初の自律型データベースクラウド構想に代表される Platform as a Service、Infrastructure as a Service を中心とした、Cloud Platformに焦点を当て、Oracleの最新テクノロジーを駆使したサービスのご紹介、および実際にクラウドサービスを活用し業務革新や新たなサービスを生みだしている企業様による取組みや効果をお話しいただきます。 セキュリティに関しても、デロイトトーマツリスクサービス様にご登壇頂き、最新トレンドとセキュリティ対策のベースラインをどう考えるべきかを解説頂きます。また、AI・自動化を活用したマルチクラウド環境におけるセキュリティ脅威の早期発見を実現するセキュリティソリューションをご紹介します。 セッション概要  -------------------------- ◆ セッション:C-1(13:15-14:00) タイトル:あなたはどうクラウドを守る?AI・自動化を使った、見えない脅威との戦い方   講演者:デロイト トーマツ リスクサービス株式会社 ディレクター 西 誉 氏 日本オラクル株式会社 クラウドプラットフォーム戦略統括 大澤 清吾   講演概要:AWS、Azure、Office 365、G Suite、Box、Slack、GitHub、Oracleなどのクラウドを安心に使うためのポイントを国内事例を交えて解説します。今、マルチクラウドの進展でますますセキュリティ対策が複雑化しています。本セッションでは、クラウドセキュリティ対策のトレンドと求められる対策、またAI・自動化を活用したマルチクラウド環境におけるセキュリティ脅威の早期発見を実現するセキュリティソリューションをご紹介します。 -------------------------- ◇ イベント開催概要 ◇ 会期:2018年7月27日(金)9:30〜17:00 (受付開始 9:00〜) 会場:ウェスティンホテル東京 主催:日本オラクル株式会社 参加費:無料 ※事前登録制 詳細内容/ご参加のお申込み => こちら

7/27(金)に Oracle Innovation Summit Tokyo 2018 が、開催されます。本イベントでは、世界初の自律型データベースクラウド構想に代表される Platform as a Service、Infrastructure as a Service...

オラクルのクラウドセキュリティソリューション (CASB / IDaaS / SIEM / UEBA)

マルチクラウド環境の進展によるセキュリティ対策の複雑化しており、弊社へもご相談を頂く機会が増えております。 OracleとKPMGによる最近公開されたセキュリティ脅威レポート「Oracle and KPMG Cloud Threat Report 2018」においては、87%の顧客がクラウドファーストを指向しており、何らかの機密データをクラウドで扱っている企業は90%になっています。 一方で、3分の2の企業は、過去2年間のセキュリティ事件によって業務が混乱していると述べており、半数以上が違反関連の財務的影響を経験したと答えており、クラウドの利用が加速する中、セキュリティ対策は非常に重要な問題になっています。 クラウドの利活用における課題においては、97%の企業はクラウドの利用ポリシーを策定しているが、社員が実際にクラウドの利用ポリシーを従うか懸念している企業が82%に上っています。また、今後の課題として「クラウドセキュリティインシデントの検出」をあげる企業が最も多く38%となっております。 このようなハイブリッドクラウドやマルチクラウド環境におけるセキュリティ対策の課題を解決するクラウドサービス群として、「Oracle Identity Security Operations Center(以下、Oracle Identity SOC)」を提供しております。 Oracle Identity SOCの特長は以下になります。 マルチクラウド・ハイブリッドクラウド対応のセキュリティ・サービス群 クラウドベースであるため、オンプレミスでもクラウド環境もログを集約しやすい シャドーITやSaaSも含めたマルチクラウドの利用状況を可視化 未知の脅威に対する検知 IDベースのユーザー行動監視(UEBA):侵入後の活動や内部不正を発見 機械学習:「いつもと違う」を検出することで未知な攻撃を発見 オートメーションによる対処 脅威に応じた自動対処により被害の最小化   ■ Oracle Identity SOC サービス概要 Oracle Identity SOC では、以下の6つのサービスを提供しており、これらのサービスは独立して利用いただくことができます。 カテゴリ ソリューション 概要 UEBA + SIEM ① Security Monitoring and Analytics Cloud Service ログ、CASB監視データ、ID情報、構成情報などあらゆる運用データの相関分析とセキュリティ脅威の可視化 CASB ② CASB Cloud Service SaaSやシャドーITを含むクラウドサービスに対するユーザー行動の可視化とセキュリティ脅威の検知 IDaaS ③ Identity Cloud Service クラウドサービスやオンプレミスアプリケーションに対する認証・認可の一元管理 フォレンジック  ④ Log Analytics Cloud Service あらゆるIT環境のログを収集、GUI&マウス操作によるインタラクティブな分析機能の提供 構成管理 ⑤ Configuration and Compliance Cloud Service セキュリティ・アセスメントの自動化によるシステム脆弱化の防止 自動レスポンスと対処 ⑥ Orchestration Cloud Service アクションのオートメーションによる、システム障害やセキュリティ脅威の早期対応、被害最小化   ■ クラウドセキュリティソリューションを活用頂いているお客様 オラクル・セキュリティお客様活用事例 (データベース・セキュリティ/クラウド・セキュリティ) ■ カタログ 準備は万全ですか?マルチクラウド時代のID管理とセキュリティ対策 マルチクラウド環境のセキュリティ、利用監視、ガバナンスを実現するには?機械学習技術を活用した高度な脅威検知と、迅速なID/アクセス管理、多層防御によるセキュリティリスクを低減するIDaaS (Identity as a Service) を簡単に実現できるサービスをご紹介します。 クラウド時代の運用管理とセキュリティ対策の最適解 IT運用の高度化とセキュリティ対策が急務となる昨今、他社クラウドもオンプレミスも含んだ運用管理、アクセス監視、セキュリティ対策など包括的なソリューションが必要です。クラウド時代に最適なセキュリティ対策、統合運用管理のソリューションをご紹介します。 技術・人・プロセスの連携で高度なセキュリティを実現するOracle Cloud Platform (※ 要認証) セキュリティ強化のためにクラウドを採用する、というパラダイムシフトが始まっています。米国最新動向、国内企業のクラウド利用動向、セキュリティ視点でのベンダー選びのポイントや、Oracle Cloud Platformが実現しているセキュリティ強化など、分かり易く解説します。 クラウドセキュリティに必須のソリューション Cloud Access Security Broker(CASB)導入のポイント (※ 要認証) 大注目のセキュリティテクノロジー”CASB"って何? クラウド時代に困難さを増すセキュリティ対策や法令順守。CASBは、クラウドサービスの利用を見える化し、安心安全な運用監視を支援するテクノロジーです。今後ますます必要となってくるクラウドセキュリティの最適解 CASB について、分かり易く解説します。   ■ 各種講演資料 ここまできた、クラウドのID管理とCASBの活用~事例を含め紹介~ (Japan Identity & Cloud Summit 2017 での講演資料) クラウドのセキュリティと運用管理 (2017/11/8-10 Japan IT Week 内 オラクルブース ミニシアター) IT運用高度化がもたらす価値 -事例から考える、これからのITサービスとセキュリティ- (2018/1/26 Oracle Cloud World Osaka での講演資料) CASB Cloud Service / Identity Cloud Service ご紹介 - Slideshare ■ Oracle Identity Security Operation Center サービス紹介動画 ■ その他参考情報 [2/5 発表] セキュリティ・IT運用管理サービス:Oracle Identity SOC Oracle Cloud :セキュリティとコンプライアンス オラクルが、ガートナー マジック・クアドラントでアイデンティティ・ガバナンスおよび管理分野の「リーダー」に位置付け 【リコー様、IDaaS事例ご紹介】 11/30 ITmediaエンタープライズ セキュリティセミナー OpenWorld 2017: Oracle Management and Security Cloud (SIEM / UEBA) 

マルチクラウド環境の進展によるセキュリティ対策の複雑化しており、弊社へもご相談を頂く機会が増えております。 OracleとKPMGによる最近公開されたセキュリティ脅威レポート「Oracle and KPMG Cloud Threat Report 2018」においては、87%の顧客がクラウドファーストを指向しており、何らかの機密データをクラウドで扱っている企業は90%になっています。 一方で、3分の2...

セキュリティ全般

[7/3開催] Fortinet Security World 2018 大阪

6/7に開催された東京のイベントに引き続き、7/3(火)に開催される Fortinet Security World 2018 大阪にて出展致します。 クラウド活用時代に考えるべき対策のポイントやAI・自動化・振る舞い検知を活用した次世代型のクラウド・セキュリティソリューションをご紹介させて頂きます。 弊社セッション概要  -------------------------- ◆ セッション:A-4(15:55-16:35) タイトル:あなたはどうデータを守る?クラウド・AI・自動化を使った、みえない脅威との戦い方 講演者:日本オラクル株式会社 クラウド・テクノロジー事業統括 Cloud Platformビジネス推進本部 大澤 清吾  講演概要: マルチクラウドの進展でますますセキュリティ対策が複雑化しています。本セッションでは、人工知能(AI)技術を活用した、マルチクラウド環境におけるセキュリティ脅威の早期発見、IT運用の高度化を実現する次世代型のクラウド・セキュリティソリューションをご紹介します。 -------------------------- ◇ イベント開催概要 ◇ 会期:2018年7月3日(火)10:15~17:40 (受付開始:9:30~) 会場:ホテル阪急インターナショナル 主催:フォーティネットジャパン株式会社 参加費:無料 ※事前登録制 詳細内容/ご参加のお申込み => こちら

6/7に開催された東京のイベントに引き続き、7/3(火)に開催される Fortinet Security World 2018 大阪にて出展致します。 クラウド活用時代に考えるべき対策のポイントやAI・自動化・振る舞い検知を活用した次世代型のクラウド・セキュリティソリューションをご紹介させて頂きます。 弊社セッション概要  -------------------------- ◆...

セキュリティ全般

[6/7開催] Fortinet Security World 2018 東京

6/7(木)に開催される Fortinet Security World 2018 東京にて出展致します。 クラウド活用時代に考えるべき対策のポイントやAI・自動化・振る舞い検知を活用した次世代型のクラウド・セキュリティソリューションをご紹介させて頂きます。 ※ 7/3のイベントにも登壇します。詳細はこちら →  [7/3開催] Fortinet Security World 2018 大阪 弊社セッション概要  -------------------------- ◆ セッション:C-1(13:30-14:10) タイトル:あなたはどうデータを守る?クラウド・AI・自動化を使った、みえない脅威との戦い方 講演者:日本オラクル株式会社 クラウド・テクノロジー事業統括 Cloud Platformビジネス推進本部 大澤 清吾  講演概要: マルチクラウドの進展でますますセキュリティ対策が複雑化しています。本セッションでは、人工知能(AI)技術を活用した、マルチクラウド環境におけるセキュリティ脅威の早期発見、IT運用の高度化を実現する次世代型のクラウド・セキュリティソリューションをご紹介します。 -------------------------- ◇ イベント開催概要 ◇ 会期:2018年6月7日(木)10:00~17:50 (受付開始:9:15~) 会場:ザ・プリンスタワー東京 コンベンションホール(地下2階) 主催:フォーティネットジャパン株式会社 参加費:無料 ※事前登録制 詳細内容/ご参加のお申込み => こちら

6/7(木)に開催される Fortinet Security World 2018 東京にて出展致します。 クラウド活用時代に考えるべき対策のポイントやAI・自動化・振る舞い検知を活用した次世代型のクラウド・セキュリティソリューションをご紹介させて頂きます。 ※ 7/3のイベントにも登壇します。詳細はこちら →  [7/3開催] Fortinet Security World 2018 大阪 弊社セッシ...

セキュリティ全般

オラクル・セキュリティお客様活用事例 (データベース・セキュリティ/クラウド・セキュリティ)

顧客事例/ニュースリリースとして発表させていただいたお客様及びメディア掲載いただいたお客様の事例をご紹介します(五十音順)。 ■ データベースセキュリティ SBIトレードウィンテック (Advanced Security, Database Vault, Audit Vault and Database Firewall) 事例 (PDF)  エディオン  (Advanced Security) 事例 (PDF) 性能向上は当然、コストも大幅削減:エディオンが「約1200店舗の業務をリアルタイムに支える統合データベース基盤」にOracle Exadataを選んだ理由 KDDIエボルバ (ファイングレイン監査, Data Masking and Subsetting) 札幌市 (Data Masking and Subsetting) セブン&アイ・ホールディングス (Advanced Security, Database Vault, Audit Vault and Database Firewall) 日本精工 事例 (PDF) 野村総合研究所 (Advanced Security, Database Vault) 白十字会 佐世保中央病院 (ファイングレイン監査, Advanced  Security) 事例 (PDF) わずか1分で移行! 佐世保中央病院がOracle GoldenGateで電子カルテの基幹DBをスピード移行。データ暗号化、先進監査機構でセキュリティも強化 バンダイ (Advanced Security, Database Vault, Audit Vault and Database Firewall, Data Masking and Subsetting) 事例 (PDF)  高速かつ高セキュリティなDB基盤が“日本発キャラクター”のグローバル展開を加速: 繁忙期のリクエスト処理能力が10倍超に! 「プレミアムバンダイ」は性能不足の問題をOracle Exadataで解決  プロトコーポレーション (Advanced Security) ベリトランス (Advanced Security) 急がれるPCI DSS準拠、ベリトランスはどう対応したのか。確実かつ効率的なソリューションは? ー クレジットカード含む全データの暗号化をどう実現したか? Oracle Magazine : Oracle Exadataの採用で、クレジットカード業界をリードする 次世代決済プラットフォームへ刷新 マツダ 三菱アルミニウム (Advanced Security) 基幹DBのBCP対策強化、管理性と性能の大幅向上を実現:三菱アルミニウムがマルチテナント機能で販売/生産管理データベースを一挙集約し、事業継続性も強化。その選択の理由とは? ヤフー (Database Vault) Oracle Database Vaultって本当に必要ですか? データを守るためよりもむしろメンバーを守るためにこそいるのです 楽天証券 (Advanced Security, Database Vault, Audit Vault and Database Firewall)     事例 DBアクセス制御、暗号化、監査で高セキュアな個人情報管理を実現:楽天証券は多層防御でマイナンバーを安全管理 オラクルのデータベースセキュリティ製品はどう使われたのか?  ラクロス (Advanced Security)  良品計画 (Audit Vault and Database Firewall) 事例 (PDF) ■ クラウドセキュリティ (国内) アウトソーシング (Identity Cloud Service / CASB Cloud Service) 株式会社アウトソーシング、統合したグループ会社のセキュリティをOracle Cloudで強化 インタビュー動画:Outsourcing Enhances Security with Oracle Identity Cloud Service ※ 参考:安心してクラウドを使うために。アウトソーシング様のセキュリティ対策とID管理の取組み - Oracle CloudWorld Tokyo 2017 リコー (Identity Cloud Service) 株式会社リコー、Oracle PaaSでセンシングソリューションをセキュアに サービス連携は数時間で完了――リコーのセンシングソリューションビジネスにおけるID管理、“柔軟性とセキュア”を両立できた理由とは リコーに聞く、デジタル時代の“ブレない”クラウドの使い方 インタビュー動画:Ricoh Expands to New Businesses with Oracle Cloud Security ※ 参考:ヒトやモノの位置をリアルタイムに可視化し、業務を最適化! デジタルを活かした『センシングソリューション』ビジネスの短期立ちあげ - Oracle CloudWorld Tokyo 2017 ※ 参考:【リコー様、IDaaS事例ご紹介】 11/30 ITmediaエンタープライズ セキュリティセミナー (データベース・セキュリティナビ) ■ クラウドセキュリティ (海外) Widget Inc (海外:Identity Cloud Service) Widget Inc. Finds Oracle Cloud to be Blindingly Fast WIND Hellas (海外:CASB Cloud Service) WIND Hellas Reduces Risk and Improves EU GDPR Compliance with Oracle Cloud Pragmatyxs (海外:Identity Cloud Service) インタビュー動画:Pragmatyxs Reduces Costs with Oracle Identity Cloud Service Levi Strauss & Co (海外:CASB Cloud Service) インタビュー動画:Levi's Speaks About Security in the Cloud UBI Banca (海外:Cloud Security) インタビュー動画:UBI Banca Chooses Oracle Security Cloud ■ ID管理・アクセス制御 (国内) 日本マクドナルド (Oracle Identity Management) 日本マクドナルド、全国約3,000の店舗、4万人規模のユーザーIDとアクセス権限を一元管理する認証基盤をクラウド上に刷新。運用コストを大幅に削減しつつ新たなサービスや利用者への拡大も可能に

顧客事例/ニュースリリースとして発表させていただいたお客様及びメディア掲載いただいたお客様の事例をご紹介します(五十音順)。 ■ データベースセキュリティ SBIトレードウィンテック (Advanced Security, Database Vault, Audit Vault and Database Firewall) 事例 (PDF)  エディオン  (Advanced Security) 事例...

データベースセキュリティ

[5/30開催] 第14回DBSC春のセミナー ~ データの越境流通についての世界の動向 ~

5/30 (水) にデータベース・セキュリティ・コンソーシアムの春セミナーが開催されます。 今回は、データの越境流通についての世界の動向を講演とパネルディスカッションを通して考察いたします。また、DBSCで調査を行った、DBA1,000人に対するアンケート1回目(2013年4月実施)と2回目(2017年12月実施)の結果とを比較/分析した調査報告をご紹介します。 日本オラクルからは、パネルディスカッションで登壇させて頂きます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━        <データベース・セキュリティ・コンソーシアム(DBSC)主催>                              第14回DBSC春のセミナー        ~ データの越境流通についての世界の動向 ~   [日時] 2018年5月30日(水) 14:30~17:30   [URL]  http://www.db-security.org/seminar/20180530.html   [会場] 東京電機大学 東京千住キャンパス1号館2F「1204セミナー室」  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 国内では、昨年5月30の個人情報保護法の改正からちょうど1年が経過しようとし、また、海外では、EU一般データ保護規則(GDPR)が本年5月25日より施行となります。 それに伴い、個人データの取扱いについて改めて関心が寄せられています。特に、GDPRでは、個人データのEU域外移転への厳しい制限があり、日本企業にも直接的に大きな影響があります。 本セミナーでは、データの越境流通についての世界の動向を講演とパネルディスカッションを通して考察いたします。また、DBSCで調査を行った、DBA1,000人に対するアンケート1回目(2013年4月実施)と2回目(2017年12月実施)の結果とを比較/分析した調査報告をご紹介します。 ご参加費は無料ですので、多くの皆様のご参加をお待ちしております。   ※ 本イベントご参加で、(ISC)2認定資格保持者様のCPEクレジット(3ポイント)が取得可能です ///// セミナー概要 //////////////////////////////////////////////////////// ■日程 / 2018年5月30日(水) 14:30~17:30 ■参加費 / 無料 ■定員 / 100名 ■会場 / 東京電機大学(東京千住キャンパス)1号館2階「1204セミナー室」              https://www.dendai.ac.jp/access/tokyo_senju.html ■内容 /  14:30~14:35   開会挨拶   14:35~15:05 講演「『DBA1,000人に聞きました』アンケート調査報告」        DBSC運営委員:北野晴人 氏 [情報セキュリティ大学院大学]  15:05~15:55 基調講演 「個人データの円滑な越境移転に向けた取組み」        小川久仁子 氏 [個人情報保護委員会事務局 参事官] 情報通信技術の発展やビッグデータの利活用の進展などのこの10年間における環境変化を踏まえ、昨年5月に我が国において改正個人情報保護法が全面施行され、本年5月にはEUにおいて一般データ保護規則(GDPR)の適用が開始される。本講演では、我が国の改正個人情報保護法の概要や施行状況とともに、個人データの円滑な越境移転に向けたEUや米国等をはじめとした諸外国との国際的連携の推進を含めた最新の動向について個人情報保護委員会事務局からご説明をさせていただく。  16:10~17:25 パネルディスカッション    パネラー   :小川久仁子 氏、          高橋正和 氏 [株式会社Preferred Networks]、          北野晴人 氏、          大澤清吾 氏 [日本オラクル株式会社]、    モデレータ:西本逸郎 氏 17:25~17:30 閉会挨拶        DBSC事務局長:西本逸郎氏 (株式会社ラック)       ~~ 内容は予告無く変更される場合もございますことご了承ください。 ~~ ※ ご参考:過去の実施イベント 明日登壇します。DBSC秋の臨時セミナー ~「ランサムウエアとDBセキュリティ」~ [2/28開催] DBSC早春セミナー ~ データ主導社会におけるデータベースセキュリティ ~  

5/30 (水) にデータベース・セキュリティ・コンソーシアムの春セミナーが開催されます。 今回は、データの越境流通についての世界の動向を講演とパネルディスカッションを通して考察いたします。また、DBSCで調査を行った、DBA1,000人に対するアンケート1回目(2013年4月実施)と2回目(2017年12月実施)の結果とを比較/分析した調査報告をご紹介します。 日本オラクルからは、パネルディスカッシ...

セキュリティ全般

【記事紹介】 セキュリティ脅威調査:62%の企業が、クラウドのセキュリティの方が優れていると回答

オラクルとKPMGが初めて共同で作成したレポート「Oracle and KPMG Cloud Threat Report 2018」が公開されました。 本レポートは、クラウドに対する組織の立場とクラウドへの信頼や課題とリスク、またセキュリティ担当が人、プロセス、テクノロジーを活用してクラウド活用を考えているかなどを450人のグローバルIT専門家に調査しました。 レポートの中では以下のような内容の対策状況について報告がされています。 企業のクラウドの利用状況 クラウド利用のポリシーの取り組み状況やその課題 クラウドとオンプレミスのセキュリティ比較 クラウドセキュリティの重要課題 脅威への迅速な対応にむけた機械学習や自動化の活用 本レポートの内容のポイントをまとめた、特集記事を公開しましたので、お時間のある時に確認ください。 「セキュリティ脅威調査:62%の企業が、クラウドのセキュリティの方が優れていると回答」 また、レポートは以下のサイトからダウンロードすることが出来ます。 Oracle and KPMG Cloud Threat Report 2018

オラクルとKPMGが初めて共同で作成したレポート「Oracle and KPMG Cloud Threat Report 2018」が公開されました。 本レポートは、クラウドに対する組織の立場とクラウドへの信頼や課題とリスク、またセキュリティ担当が人、プロセス、テクノロジーを活用してクラウド活用を考えているかなどを450人のグローバルIT専門家に調査しました。レポートの中では以下のような内容の対策状...

セキュリティ全般

いよいよ施行。GDPR対応のポイント ~明示的同意取得とデータセキュリティ対策~

2018年5月25日より適用開始され、継続的な対応が求められるEU GDPR(一般データ保護規則)。 今一度、GDPR 対応で何が求められるかを確認するためのホワイトペーパや特集記事や事例がありますので、是非ご確認ください。 ■ 事例 UBI Banca 様 :GDPR対応とクラウドセキュリティ対策を目的としたオラクルのソリューションを活用 UBI Banca Secures their Cloud using Oracle CASB Cloud Service   ■ 特集記事 いよいよ明日施行!欧州GDPR:「Cookie」のBefore/Afterで考える5つのポイント   ■ ホワイトペーパ GDPR対応のポイント~明示的同意取得とデータセキュリティ対策~ 情報セキュリティ・コンサルタントの佐藤慶浩氏に、GDPR対応におけるポイントを解説して頂いています。今回は、明示的同意取得とデータセキュリティ対策を中心に解説を頂きました。万全な体制でGDPR施行を迎えるために、本文書をご活用下さい。 セキュリティのポイント ダイジェスト紹介: ・認証(Authentication)の厳格化:アクセス者の特定 ・認可(Authorization)の厳格化:アクセス権の最少化 ・管理(Administration)の厳格化:認証と認可の適切な維持 ・監査(Audit)の厳格化:認証・認可・管理の証跡の保全 ・データ自身の保護:暗号化(Encryption) EU一般データ保護規則(GDPR)への対応強化~Oracle Database Security製品の活用~ オラクルのデータベースセキュリティ製品でGDPRの要件にどのように対処できるかを「GDPRと製品機能の対応表」付きで解説します。実際に架空企業を例に解決策を例示します。 GDPR遷守のための対応を支援するオラクルのセキュリティ・ソリューション GDPRセキュリティ対策には、データ暗号化、アクセス制御、監査などアーキテクチャで実装できるものがあります。エンフォースメントにおける4つのセキュリティ要件と、対応するオラクルのセキュリティ・ソリューションを解説します。 また、GDPR対応も含めたクラウドおよびオンプレミスのデータベースを保護するための様々な具体的な対策をまとめた Securing the Oracle Database  もございますので、こちらもご利用下さい。

2018年5月25日より適用開始され、継続的な対応が求められるEU GDPR(一般データ保護規則)。 今一度、GDPR 対応で何が求められるかを確認するためのホワイトペーパや特集記事や事例がありますので、是非ご確認ください。 ■ 事例 UBI Banca 様 :GDPR対応とクラウドセキュリティ対策を目的としたオラクルのソリューションを活用 UBI Banca Secures their Cloud...

データベースセキュリティ

DBSATのダウンロードが5000件を超えました

-- この記事は「Celebrating 5,000 Database Security Assessment Tool (DBSAT) downloads!」(2018/4/17)の和訳です -- Oracle Database Security Assessment Tool (DBSAT) のダウンロード数が5000件を超えました。 2018年1月中旬のDBSAT v2.0.1リリース以降、需要が高まっており、好評を得ています。 DBSATは現在のデータベースセキュリティを状態を評価する人気のあるツールです。その理由は以下の通りです。 シンプルでセキュリティの知識がなくても利用できます。インストールは解凍するだけで、読みやすいレポートを出力できます。 即時に価値を提供します。総合的な構成と運用上のセキュリティのリスクだけでなく、ユーザーや権限についてもレポートします。何が危険なのかをよく理解するために、DBSATは重要な個人情報を発見するためにも役立ちます。 GDPRコンプライアンス対応の取り組みの支援:GDPRと技術的な制御の間のギャップを埋めるために、関連する調査結果を強調し、どのようなセキュリティ制御が有効か推奨事項を提示します。同様にOracle Database CIS ベンチマークに関連する調査結果も強調します。 GDPRの期限である2018年5月25日が近づいています。また、Verizon new 2018 Data Breach Investigations Reportでウェブサーバーやデスクトップよりもデータベースが最も侵害された資産であること(割合にして20%弱)が裏付けられました。ハッカーより先に現在のデータベースセキュリティの状態を確認することは急務です。 実際にDBSATを見たいですか? RSA Conference 2018でオラクルブース(#1115 Moscone South)にぜひご来場ください。 日本のお客様は、担当のオラクル営業もしくはOracle Digitalまで。 関連情報: [第2回] Oracle Databaseのセキュリティリスクチェックツール - Database Security Assessment Tool (DBSAT) [第61回] Database Security Assessment Tool Version 2 公開

-- この記事は「Celebrating 5,000 Database Security Assessment Tool (DBSAT) downloads!」(2018/4/17)の和訳です -- Oracle Database Security Assessment Tool (DBSAT) のダウンロード数が5000件を超えました。2018年1月中旬のDBSAT...

ID管理・認証

オラクルが、ガートナー マジック・クアドラントでアイデンティティ・ガバナンスおよび管理分野の「リーダー」に位置付け

オラクルが「Gartner Magic Quadrant for Identity Governance and Administration」でリーダーの位置付けになりました。 本件については、USで以下の内容でプレス発表済みです。   - Oracle Named a Leader in the 2018 Gartner Magic Quadrant for Identity Governance and Administration 本発表のポイントは以下になります。 5年連続で「Magic Quadrant for Identity Governance and Administration」でリーダーに位置付け 本年度は「ビジョンの完全性」で最も高いポジションの位置付け 「Magic Quadrant for Access Management」と共にリーダーの位置付け これは、オラクルがこの1年間に提供したクラウド・セキュリティ・サービスの強みと革新性、および企業がビジネスを推進する上で、より統合されたセキュリティソリューションが高く評価されたと考えられます。 図:Magic Quadrant for Identity Governance and Administration 日本においても、2018年2月に「日本オラクル、複雑化するマルチクラウド環境に対応するセキュリティ・IT運用管理サービス群を拡充」を発表し、独自のAI技術を活用した「Oracle Identity SOC(Security Operations Center)」を提供開始しました。 Oracle Identity Cloud Service, Oracle CASB Cloud Service, Oracle Management Cloudが統合された「Oracle Identity SOC」を利用することで、企業はリスクの発生可能性や影響度に応じてセキュリティとIT運用・管理の態勢を迅速に適合させることができます。このAI技術により、攻撃の防止、検出に要する時間を数カ月単位から分単位へ短縮、セキュリティ侵害とパフォーマンス低下へのより迅速な対応に役立ちます。 日本での導入も進んでおり、以下のお客様の事例も公開させて頂いております。 アウトソーシング様 株式会社アウトソーシング、統合したグループ会社のセキュリティをOracle Cloudで強化 インタビュー動画:Outsourcing Enhances Security with Oracle Identity Cloud Service リコー様 インタビュー動画:Ricoh Expands to New Businesses with Oracle Cloud Security サービス連携は数時間で完了――リコーのセンシングソリューションビジネスにおけるID管理、“柔軟性とセキュア”を両立できた理由とは 本ソリューションの概要紹介資料は、以下のサイトにございます。 Oracle Identity SOC ソリューション概要 CASB Cloud Service / Identity Cloud Service ご紹介  製品カタログ:クラウド時代の運用管理とセキュリティ対策の最適解 [関連情報] Oracle IDM製品が、ガートナー マジック・クアドラントでアクセス管理分野の「リーダー」に位置付けられました [2/5 発表] セキュリティ・IT運用管理サービス:Oracle Identity SOC オラクル・セキュリティお客様活用事例 (データベース・セキュリティ/クラウド・セキュリティ) ※ 本図表は、ガートナー・リサーチの発行物の一部であり、評価するには発行物全体をご覧いただく必要があります。ガートナーの発行物は、リクエストにより日本オラクルからご提供することが可能です。 ガートナーは、ガートナー・リサーチの発行物に掲載された特定のベンダー、製品またはサービスを推奨するものではありません。また、最高のレーティング又はその他の評価を得たベンダーのみを選択するよう助言するものではありません。ガートナー・リサーチの発行物は、ガートナー・リサーチの見解を表したものであり、事実を表現したものではありません。ガートナーは、明示または黙示を問わず、本リサーチの商品性や特定目的への適合性を含め、一切の保証を行うものではありません。 Source: Gartner, Magic Quadrant for Access Management, Worldwide, 07 June 2017 ID: G00315479 Analysts : Gregg Kreizman,  Anmol Singh Source: Gartner  Magic Quadrant for Identity Governance and Administration |Published: 21 February 2018 ID: G00326925 Analyst(s): Felix Gaehtgens, Kevin Kampman, Brian Iverson

オラクルが「Gartner Magic Quadrant for Identity Governance and Administration」でリーダーの位置付けになりました。 本件については、USで以下の内容でプレス発表済みです。   - Oracle Named a Leader in the 2018 Gartner Magic Quadrant for Identity...

データベースセキュリティ

[第63回] DBSATのスクリプト実行がデータベースに与える影響

本連載の第2回「Oracle Databaseのセキュリティリスクチェックツール - Database Security Assessment Tool (DBSAT)」と第61回「Database Security Assessment Tool Version 2 公開」で紹介したDBSAT(Database Security Assessment Tool)はスクリプトを実行するだけでデータベースのセキュリティ対策状況を可視化できる便利なツールですが、スクリプトを実行する際にデータベースへの影響はどの程度あるのかという質問をよく受けます。 結論から言うと、影響はほとんどありません。スクリプトの実行にためらっていたお客様でも実際にスクリプトを流していただくと「なんだこんなもんか」という感想を持っていただいています。 DBSATのスクリプトはデータベースのメタ情報(データディクショナリ)へのSELECT処理、設定情報ファイルの確認(読み込み処理)、パッチ適用状況確認やファイルパーミッションなどのための軽量のOSコマンド実行が含まれ、これらの処理をシリアルで順番に実行していきます。そのためCPUへの影響は1コアの範囲内に収まります。業務データを読み込んだり、データベースに対する変更処理はありませんので、業務データが格納されているストレージへのI/Oもありません。 実際にどのようなコマンドが実行されるかは、スクリプトが公開されていますので、心配であれば事前にどのようなコマンドを発行しているか確認することもできます。 不正アクセスや操作ミスによる想定外の設定を発見するためにスクリプトは本番環境で実行する必要がありますが、多くのお客様では本番環境で実行する前に検証環境などで試しに実行してみて影響が出ないことを確認いただいています。 百聞は一見に如かず。ぜひ、まずは試してみてください。 「もくじ」にもどる

本連載の第2回「Oracle Databaseのセキュリティリスクチェックツール - Database Security Assessment Tool (DBSAT)」と第61回「Database Security Assessment Tool Version 2 公開」で紹介したDBSAT(Database Security Assessment Tool)はスクリプトを実行するだ...

データベースセキュリティ

【記事紹介】 急がれるPCI DSS準拠、ベリトランスはどう対応したのか。確実かつ効率的なソリューションは?

2017年12月に開催した 「Oracle CloudWorld Tokyo」での「【対応迫る:PCI DSS】カード情報はこう管理する。ベリトランスのセキュリティとデータ保護の仕組み」のセッションで登壇頂いたベリトランス様の講演内容が記事として掲載されました。 PCI DSS ですが、2018年6月に改正割賦販売法が施行され、クレジットカード情報の漏えい対策が義務化されるなど、関心が高い分野になります。 データ保護対策としてPCI DSSの要件にどのように対応されたか参考となる情報となりますので、是非ご興味ある方は参考にして頂ければと思います。 ▼記事タイトル 急がれるPCI DSS準拠、ベリトランスはどう対応したのか。確実かつ効率的なソリューションは? ―クレジットカード含む全データの暗号化をどう実現したか? ▼記事ページURL http://www.atmarkit.co.jp/ait/articles/1804/04/news003.html また、その他のデータベースセキュリティの事例は、下記のサイトから確認できます。 オラクル・セキュリティお客様活用事例 (データベース・セキュリティ/クラウド・セキュリティ) ---------------------------------------------------- ご参考:CloudWorld Tokyo でのセッション概要   ---------------------------------------------------- ◆ セッション:H-3(15:15-16:00) タイトル:【対応迫る:PCI DSS】カード情報はこう管理する。ベリトランスのセキュリティとデータ保護の仕組み 講演者:ベリトランス株式会社 取締役執行役員CTO 赤尾 浩平 氏             日本オラクル株式会社 クラウド・テクノロジー事業統括 Cloud Platformビジネス推進本部 大澤 清吾  講演概要:PCI DSS、改正個人情報保護法、EU GDPR対応など、データベースに対するセキュリティ強化の波が途絶えることはありません。 今回は、ベリトランスがどのようにお客様からお預かりしているクレジットカード情報や個人情報を、安心・安全な仕組みで管理・保護しているかをご紹介頂き、最適なセキュリティ対策をデータベースで行う際の勘所をご紹介します。

2017年12月に開催した 「Oracle CloudWorld Tokyo」での「【対応迫る:PCI DSS】カード情報はこう管理する。ベリトランスのセキュリティとデータ保護の仕組み」のセッションで登壇頂いたベリトランス様の講演内容が記事として掲載されました。 PCI DSS ですが、2018年6月に改正割賦販売法が施行され、クレジットカード情報...

ID管理・認証

[第62回] 個人IDの作成だけでは「匿名性の排除」は実現できない

SYS、SYSTEMといったデータベースの事前定義の管理ユーザーやアプリケーションのユーザーを複数のデータベース管理者、アプリケーション管理者で共有しているシステムはまだまだ多いのが現状です。強力な権限を持ったユーザーを共有して利用することは、必要以上の操作をおこなうことができ、誰が操作したかを特定しにくくなるため、情報漏えいなどの不正アクセスのリスクを高め、その被害を増大させます。また、みんながパスワードを知っている状態にあるため、部署異動や退職などでその業務をおこなわなくなった後でもデータベースにアクセスするための認証情報を知っている状態になります。このような状態でも、特にアプリケーションのユーザーのパスワードは複数のプログラムやアプリケーションサーバーに埋め込まれていることが多いので変更することができないケースも多いです。 誰が操作したかを特定し、部署異動や退職でアクセスの必要がなくなった後に確実にアクセスできないようにするためには、データベースに直接アクセスする利用者には個人用のデータベースユーザーを作成して、利用者がデータベースにアクセスする必要がなくなった時にはそのユーザーを削除する仕組みが必要です。 ただし、既存システムで個人用のユーザーを作成するだけでは匿名性の排除することはできません。個人用のユーザーを利用するようにガイドしていても、共有していたアカウントがそのまま残っている場合、そのパスワードを知っていればそのアカウントも利用しつづけることができてしまいます。通常の運用は個人用のユーザーを利用していても、たとえばそのユーザーでは権限がなくてできない処理があった場合、パスワードを知っているSYSTEMユーザーで接続して作業をおこなってしまうかもしれません。また、データ盗難など悪いことをしようとした際には、犯人が特定されやすい個人用のユーザーではなく、個人を特定できない共有ユーザーを使おうとすることは想像しやすいです。 匿名性を排除するためには、個人用のIDの利用を徹底するだけではなく、共有IDを利用できないようにすることが重要です。 共有IDを利用できないようにするための根本的な解決方法はSYS、SYSTEMといった事前定義の管理ユーザーやアプリケーション、バッチ用などプログラムが利用するユーザーのパスワードを知られないようにすることです。新しくシステムを構築する場合には可能かもしれませんが、既存システムの場合、前述の通りパスワードを変更することができない場合もあります。 また、Oracle Databaseの場合、データベースサーバーのOSの特定の(例えばdba)グループに所属しているユーザーは、OSで認証されている場合、データベースで再度認証されることなくSYSユーザーとしてデータベースに接続できますので、OSユーザーの管理も重要となります。 このようにパスワードが知られていたりOSで代理認証されたりするなど個人用のID以外でデータベースに接続できてしまう場合、認証をさらに厳密にしたり、接続されてもデータにアクセスできないようにする仕組みが必要です。この対策は新規システムにおいても万が一のパスワードが攻撃者に知られてしまった場合でも情報漏えいしないようにするためにも活用できます。 具体的には「アクセス経路の限定」をおこないます。たとえばデータベースサーバーOSやデータベースサーバーに接続できる元を制限します。ネットワーク層でアプリケーションサーバーや運用端末以外からのアクセスを遮断する方法があります。ただし、ネットワーク層でのアクセス経路の制限では、IPアドレスレベルの対応は可能ですが、データベースユーザーごとの対応はできません。そのためアプリケーションサーバーからデータベース管理ユーザー(SYSやSYSTEM)での接続を制限することはできません。 データベースユーザーやアクセス元のIPアドレス、アプリケーション、OSユーザー、時間など詳細な条件を組み合わせて接続の許可・遮断やデータへのアクセスの許可・遮断を実施したい場合には、Oracle Database Vaultを利用する必要があります。Oracle Database Vaultを利用することで、データベース管理ユーザー(SYS、SYSTEM)を含めたすべてのデータベースユーザーに対してアクセス制御を実現することが可能となります。 また共有IDが不正に利用されていないことを確認するために「監査と監視」が重要になります。Oracle Databaseではリリースされた最初のバージョン(Oracle V2)から監査機能がついていました。Oracle Database 11gからはデフォルトの監査設定が変更され、ログイン成功および失敗の監査が自動的に有効化されています。Oracle Database 12cからは、ログイン失敗のみ監査するようデフォルト値が変更になっていますが、不正利用がなかったことを確認するためにはログイン成功も監査することが必要です。Oracle Database 12c以降の統合監査では、詳細な監査条件を指定できるためアプリケーション用のユーザーが想定されたアプリケーション(IPアドレス、OSユーザー、プログラム名など)以外からログインがあったときのみ監査するといった設定ができます。 取得した監査ログは、たとえばアプリケーション用のIDでアプリケーション以外から直接データベースに接続した形跡がないか、計画外のデータベース管理ユーザーでの接続がないかを定期的に確認することで、不正アクセスにいち早く気づくことができます。またこのような監視の仕組みを導入しているしていることを広く認知させることで、内部不正の抑止効果も期待できます。 コンプライアンス対応などのために、データベースに対しても個人用のIDを作成することが少しづつ一般化してきているように感じます。しかし、個人用のIDを作成するだけでなく、共有IDを利用できないようにしないと、個人用のIDを作成した意味が薄れてしまいますので注意が必要です。   この連載の第1回「はじめに ~ データベースセキュリティの基本的な考え方」では、データベースのセキュリティを担保するうえで重要なポイントとして以下の5つをあげています。 共有ユーザー利用などの匿名性を排除する 重要なデータは集中管理し、アクセス経路を限定する 最小権限の原則に則ったアクセス制御を強制する 暗号化したほうがよいか迷うものは、すべて暗号化する 監査するだけでなく、監視する これらはすべて単体で考えるものではなく、今回「匿名性の排除」のために「アクセス経路を限定」したり、確認のために「監査と監視」をおこなう必要があると説明したように互いに補完しあいながら機能しています。既存のシステムに対してすべてを一度に実施することは難しいかもしれませんが、これらのポイントを気にかけながら運用改善、新規システムの構築をぜひ実施していってください。 「もくじ」にもどる          

SYS、SYSTEMといったデータベースの事前定義の管理ユーザーやアプリケーションのユーザーを複数のデータベース管理者、アプリケーション管理者で共有しているシステムはまだまだ多いのが現状です。強力な権限を持ったユーザーを共有して利用することは、必要以上の操作をおこなうことができ、誰が操作したかを特定しにくくなるため、情報...

[記事紹介] マルチクラウド時代の“隙”を狙うサイバー攻撃にどう対応すべきか (@ITセキュリティセミナー2018.2)

2018年2月に実施した @ITセキュリティセミナー  での弊社セッション「あなたはどうデータを守る?クラウド・AI・自動化を使った、みえない脅威との戦い方」の講演内容が記事として公開されました。 マルチクラウド時代の“隙”を狙うサイバー攻撃にどう対応すべきか――日本オラクル 本セッションでは、クラウド活用の進展によるセキュリティの課題と、AI技術を活用した、マルチクラウド、ハイブリットクラウド環境におけるセキュリティ脅威の早期発見、IT運用の高度化を実現する次世代型の セキュリティ・IT運用管理サービス「Oracle Identity SOC」を紹介させて頂きました。 本講演資料は、以下から確認頂けますので、ぜひご覧ください。 あなたはどうデータを守る?クラウド・AI・自動化を使った、みえない脅威との戦い方 from オラクルエンジニア通信  

2018年2月に実施した @ITセキュリティセミナー  での弊社セッション「あなたはどうデータを守る?クラウド・AI・自動化を使った、みえない脅威との戦い方」の講演内容が記事として公開されました。 マルチクラウド時代の“隙”を狙うサイバー攻撃にどう対応すべきか――日本オラクル 本セッションでは、クラウド活用の進展によるセキュリティの課題と、AI技術を活用した、マルチクラウド、ハイブリットクラウド環境にお...

ID管理・認証

[記事紹介] リコーのセンシングソリューションビジネスにおけるID管理、“柔軟性とセキュア”を両立できた理由とは

昨年の 11/30 ITmediaエンタープライズ セキュリティセミナーでもご登壇頂いた リコー様のマルチクラウド環境を用いたセンシングソリューションのID管理基盤として、IDaaS製品でのOracle Identity Cloud Service(IDCS) を活用頂いている事例記事が@ITで公開されました。 リコー様が得意とされているセンシング技術をIoT/クラウドと組み合わせて独自の付加価値を創出するRFIDを活用した「病院向けソリューション」「スマートシティープラットフォーム」などビジネス面から、これらのソリューション/プラットフォームにおいて、柔軟なサービス連携と強固なセキュリティの両立を可能にしているのがID管理基盤が必要になったかについて分かりやすくご紹介頂いております。 また、Oracle IDCSの採用背景の理由やそのメリットも併せてお話頂いております。 ▼記事 サービス連携は数時間で完了 ――リコーのセンシングソリューションビジネスにおけるID管理、“柔軟性とセキュア”を両立できた理由とは   

昨年の 11/30 ITmediaエンタープライズ セキュリティセミナーでもご登壇頂いた リコー様のマルチクラウド環境を用いたセンシングソリューションのID管理基盤として、IDaaS製品でのOracle Identity Cloud Service(IDCS) を活用頂いている事例記事が@ITで公開されました。 リコー様が得意とされているセンシング技術をIoT/クラウドと組み合わせて独自の付加...

データベースセキュリティ

[2/28開催] DBSC早春セミナー ~ データ主導社会におけるデータベースセキュリティ ~

2/28 (水) にデータベース・セキュリティ・コンソーシアムの早春セミナーが開催されます。 今回は、DBAに対するアンケート1回目(2013年4月実施)の結果と2回目(2017年12月実施)の結果とを比較/分析した結果をご紹介や情報セキュリティ大学院大学 特任教授の林様や総務省 政策統括官(情報セキュリティ担当)の谷脇様からもご講演、最後に講演者の方々とのパネルディスカッションと皆様の参考となる情報を提供させて頂きますので、是非ご参加下さい。 日本オラクルからは、DBSC会員企業によるソリューション紹介で登壇させて頂きます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━        <データベース・セキュリティ・コンソーシアム(DBSC)主催>                             第13回DBSC早春セミナー     ~ データ主導社会におけるデータベースセキュリティ ~   [日時] 2018年2月28日(水) 13時00分~17時30分   [URL]  http://www.db-security.org/seminar/20180228.html   [会場] 東京電機大学 東京千住キャンパス1号館2F「1204,1205,1206セミナー室」  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ あらゆる機器や物がインターネットとつながり、ビッグデータをAI解析し、利活用するデータ主導社会。 近い将来のその実現にあたり重要な点の一つが、言わずと知れたセキュリティ対策です。 また、データのグローバル化に伴い外国の法律知識も欠かせなくなってきています。 今回のセミナー前半では、DBAに対するアンケート1回目(2013年4月実施)の結果と2回目(2017年12月実施)の結果とを比較/分析した結果をご紹介します。 特別講演では、各国の新しい法規制によるデータ囲い込みにおいて発生するであろう問題や課題についてお話いただきます。 後半では、基調講演として、総務省「IoTセキュリティ総合対策」策定の背景や方向性についてご紹介いただきます。最後は、講演者の方々とのパネルディスカッションを行います。 本セミナーは、DBSC会員だけではなく、一般の方もご参加いただけますので、ぜひ多くの皆様のご参加をお待ちしております。   ※ 本イベントご参加で、(ISC)2認定資格保持者様のCPEクレジット(4p)が取得可能です ///// セミナー概要 ////////////////////////////////////////////////////////   ■日程 / 2018年2月28日(水) 13時00分~17時30分 [受付開始 12時30分] ■参加費 / 無料 ■定員 / 250名 ■会場 / 東京電機大学(東京千住キャンパス)1号館2階「1204,1205,1206セミナー室」              https://www.dendai.ac.jp/access/tokyo_senju.html ■内容 /  13:00~13:10 開会挨拶 DBSC会長:安田浩氏 (東京電機大学 学長)    13:10~13:50 講演「『DBA1,000人に聞きました』アンケート調査報告」        DBSC運営委員:北野晴人 氏 [情報セキュリティ大学院大学]  2013年の調査から5年弱が経過し、データベースのセキュリティ対策は進んだのか?進んでいないのか?を改めて調査すべく、再びデータベースに関わって仕事をしている方1000人にアンケート調査を行った。今回はDBAの方々がCSIRTなど社内のセキュリティ組織や対策などにどのように関わっているか、についても調査している。この結果をご紹介し、今後のデータベースセキュリティを考えたいと思う。   13:50~14:30 特別講演 「データの公正な利用(Fair Use of Information)のための保有と管理」        林紘一郎 氏 [情報セキュリティ大学院大学 特任教授] 14:30~15:00 DBSC企業紹介 15:00~15:15 休憩 15:15~15:55 基調講演 「データ主導社会の実現とサイバーセキュリティ」        谷脇康彦 氏 [総務省 政策統括官(情報セキュリティ担当)]  IoTセキュリティの重要性が多方面で指摘される中、総務省では昨年10月に「IoTセキュリティ総合対策」を策定・公表した。この総合対策の背景、検討項目、検討状況、目指すべき方向性などについて解説する。 15:55~17:25 パネルディスカッション 17:25~17:30 閉会挨拶        DBSC事務局長:西本逸郎氏 (株式会社ラック)       ~~ 内容は予告無く変更される場合もございますことご了承ください。 ~~ ※ ご参考:過去の実施イベント 明日登壇します。DBSC秋の臨時セミナー ~「ランサムウエアとDBセキュリティ」~  

2/28 (水) にデータベース・セキュリティ・コンソーシアムの早春セミナーが開催されます。 今回は、DBAに対するアンケート1回目(2013年4月実施)の結果と2回目(2017年12月実施)の結果とを比較/分析した結果をご紹介や情報セキュリティ大学院大学 特任教授の林様や総務省 政策統括官(情報セキュリティ担当)の谷脇様からもご講演、最後に講演者の方々とのパネルディスカッションと皆様の参考となる情報...

[1/26 開催] Oracle CloudWorld Osaka

明日、Oracle Cloud World Osaka が開催されます。 セキュリティに関しては以下のセッションを実施いたします。 ご都合のつく方、是非ご参加ください。 セッション概要  -------------------------- ◆ セッション:F-3(15:15-16:00) タイトル:情報漏洩の原因からみる最後にデータを守るための3つの対策 -アセスメント事例にみる背景とその効果- 講演者:日本オラクル株式会社 クラウド・テクノロジー事業統括 Cloud Platformビジネス推進本部 大澤 清吾  講演概要: PCI DSS、EU GDPR、改正個人情報保護法など年々、データベースに対するセキュリティ強化の波が途絶えることはありません。クラウドへの安全性を問う声も多い昨今ですが、社内システムのデータが適切な管理をされているかを改めて確認する企業も少なくありません。最適なセキュリティ対策をデータベースで行う際のベストプラクティスを事例を交えてご紹介します。 ◆ セッション:B-4(16:15-17:00) タイトル:IT運用高度化がもたらす価値 -事例から考える、これからのITサービスとセキュリティ- 講演者: 日本オラクル株式会社 クラウド・テクノロジー事業統括 Cloud Platformビジネス推進本部 大澤 清吾  日本オラクル株式会社 クラウド・テクノロジー事業統括 Cloud Platformビジネス推進本部 小幡 創 講演概要: ログを活用してトラブルを早期に解決したい、セキュリティ脅威を迅速に発見し対処したい、利用者が実際に体感しているパフォーマンス・サービスレベルを可視化・分析したいなど、従来のIT運用・セキュリティ対策だけではできていなかった高度な施策に取り組まれるお客様が増えています。 本セッションでは、最近のお客様の取り組み事例と、「IT運用」と「セキュリティ対策」を統合した最新ソリューションをご紹介します。  -------------------------- ◇ イベント開催概要 ◇ 開催日時:2018年1月26日(金)10:00〜18:00 会場:ナレッジキャピタル コングレコンベンションセンター 住所:大阪市北区大深町3-1 グランフロント大阪 北館 B2F 会場アクセス:http://www.oracle.co.jp/events/cloudworld/2018/osaka.html#secAccess 参加費:無料 詳細内容/ご参加のお申込み ⇒ こちら

明日、Oracle Cloud World Osaka が開催されます。 セキュリティに関しては以下のセッションを実施いたします。 ご都合のつく方、是非ご参加ください。 セッション概要  -------------------------- ◆ セッション:F-3(15:15-16:00) タイトル:情報漏洩の原因からみる最後にデータを守るための3つの対策 -アセスメント事例にみる背景とその効果- 講演者:...

暗号化

[第60回] 既存表領域の暗号化表領域への変更

データベースの暗号化を利用しようとしたとき、新しくシステムを構築する際には新規に暗号化表領域を作成してその表領域に表や索引を作成すればよいのですが、既存のシステムでは既に暗号化されていない表領域に表や索引などのデータが存在しています。この既存のデータを暗号化するEncryption Conversion機能が12cR2から提供されています。 Encryption ConversionにはOnlineとOfflineの2つのモードがあります Online Encryption Conversionはデータベースを動かしたままで、通常の暗号化されていない表領域を暗号化表領域に変換する機能です。暗号化されていない表領域を暗号化しながら別の領域にコピーを作成し、コピー中の変更をコピーした暗号化したデータにも適用して、最後に暗号化した領域に切り替えるという動作となります。一度データを別の領域にコピーするため、暗号化したい表領域と同じサイズの空き領域が必要となります。また、データファイルがコピーされるため、データファイル名を変更する必要があります。 Online Encryption Conversionのコマンドは以下の通りです。 alter tablespace app1 encryption online using 'AES256' encrypt file_name_convert=('app1.dbf','app1_enc.dbf'); 「'AES256'」には暗号化アルゴリズムを指定します。「file_name_convert=('target.dbf','target_enc.dbf')」では新しく作成するデータファイルの命名規則を文字列置換のパターンで指定します。 また、Online Encryption Conversion機能を利用して、格納データを暗号化している表領域暗号鍵や暗号化アルゴリズムを変更(REKEY)したり、表領域全体を復号(DECRYPT)したりすることもできます。 Offline Encryption Conversionは表領域もしくはデータファイルをOfflineにしてデータへの問い合わせができない状態で通常の暗号化されていない表領域を暗号化表領域に変換する機能です。Offlineモードでは表領域のデータを直接暗号化していくため、暗号化中にデータにアクセスはできませんが余分な領域が不要だというメリットがあります。また、利用できる暗号化アルゴリズムはAES128のみとなります。なお、Offline Ecnryption Conversionではデータが格納されているかどうかにかかわらずデータファイルの全体を暗号化します。そのためたとえ格納されているデータ量が少なくても、データファイルのサイズが大きい場合にはコマンドが完了するまでに想定外の時間がかかることがあります。かかる時間は暗号化のためのプロセッサの速度とディスクI/O性能に依存しますので、利用している環境で時間計測用に適当な大きすぎないサイズの表領域を作成し、その表領域に対してOffline Encryption Conversionを実施することでその環境での基準となる時間を計測することができます。基準となるサイズと時間が分かれば実際に暗号化したい表領域のサイズとなるように時間をかければ処理時間を推定できます。 Offline Encryption Conversionのコマンドは以下の通りです。 alter tablespace app1 encryption offline encrypt; もしくは alter database datafile '/opt/oracle/oradata/orcl/orclpdb/app1.dbf' encrypt; Offline Encryption ConversionはALTER TABLESPACEで表領域全体を一度に、もしくはALTER DATABASE DATAFILEでデータファイルごとに実施することができます。なお、11gR2および12cR1へのバックポートはALTER DATABASE DATAFILEを利用したOffline Encryption Conversionのみで、ALTER TABLESPACEを利用したOffline Encryption Conversionは利用できませんのでご注意ください。 Offline Encryption Conversionは11gR2(11.2.0.4)および12cR1(12.1.0.2)に対してバックポートされています。パッチの適用は必要となりますが、既存の表領域を暗号化表領域に移行するコマンドを最新バージョンのデータベースでなくても利用することができます。パッチ番号などの詳細はOracle Supportのドキュメント「Enable Transparent Data Encryption (TDE) Using Fast Offline Conversion in 11.2.0.4  and 12.1.0.2 (ドキュメントID 2148746.1)」をご参照ください。なお、Offline Encryption Conversion機能を利用して暗号化した表領域は、Offline Encryption Conversion機能を利用して表領域全体を復号(DECRYPT)ことができます。さらに、12cR2であればOnline Encryption Conversionを利用することで、Offline Encryption Conversionを利用して暗号化した表領域の格納データを暗号化している表領域暗号化鍵や暗号化アルゴリズムを変更(REKEY)することができます。 Encryption Conversionを利用できないバージョンの場合でも、既存の表や索引などのオブジェクトを暗号化表領域に移動することで既存のアプリケーションの表を暗号化することができます。表の表領域を移動する方法としては、エクスポート/インポート、オフラインでの表の再定義(ALTER TABLE MOVE TABLESPACE)、オンラインでの表の再定義(DBMS_REDEFINITION)などがあります。ただし、やはり簡単なのはEncryption Conversion機能ですし、Encryption Conversionが利用できないバージョンは新規の修正パッチを作成するサポート期間が完了しています。暗号化を機に最新の脆弱性対策ができているサポート期間内であるバージョンにアップグレードすることをお勧めします。 「もくじ」にもどる

データベースの暗号化を利用しようとしたとき、新しくシステムを構築する際には新規に暗号化表領域を作成してその表領域に表や索引を作成すればよいのですが、既存のシステムでは既に暗号化されていない表領域に表や索引などのデータが存在しています。この既存のデータを暗号化するEncryption Conversion機能が12cR2から提供されています。 Encryption...

暗号化

[第59回] 透過的データ暗号化の利用方法

透過的データ暗号化機能は、Oracle Database Enterprise Editionであれば、バイナリの追加インストールなしでそのまま利用することができます。Oracle Database Standard Editionを利用している場合には、Enterprise Editionへのアップグレードが必要となります。(もちろん利用にはEnterprise EditionとAdvanced Securityオプションのライセンスを持っていることが前提となります。) 透過的データ暗号化を利用するためにはまず暗号鍵を構成する必要があります。「[第57回] 透過的データ暗号化機能」で説明した通り、データベース管理者が管理する鍵はマスター鍵と呼ばれる鍵1つだけです。マスター鍵はOracle Keystore(以降キーストアと表記)と呼ばれるファイルもしくはHSM(Hardware Security Module)に格納できますが、今回はOracle Keystoreを利用します。 キーストアを構成するためには、まずキーストアを配置するディレクトリをsqlnet.oraファイルに記述します。sqlnet.oraファイルはデフォルトでは$ORACLE_HOME/network/adminにあるファイルが参照されます。 ENCRYPTION_WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /opt/oracle/admin/orcl/wallet))) 次にキーストアを作成します。 キーストアの作成はSQL*PlusからADMINISTER KEY MANAGEMENT文でおこないます。ADMINISTER KEY MANAGEMENTはデータベースインストール時に指定した暗号鍵管理グループに所属するユーザーか暗号鍵管理権限(SYSKM)を持つユーザーで実行する必要があります。 ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/opt/oracle/admin/orcl/wallet' IDENTIFIED BY oracle12c; ここで「'/opt/oracle/admin/orcl/wallet'」はsqlnet.oraファイルで指定したキーストアの場所を、「oracle12c」はキーストアのパスワードを示しています。 作成が成功すると、指定した場所にewallet.p12というファイルが作成されます。しかし、この状態ではキーストアは利用可能な状態ではないため、以下のコマンドで利用可能な状態にします。 ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY oracle12c; 上記のコマンドでキーストアが利用可能な状態となります。なお、データベースを一度停止させ、その後起動した際にはキーストアはデフォルトでは利用できない状態です。データベース起動後には毎回上記のコマンドを発行する必要があります。 なお、後述の自動オープンキーストアを利用すると、データベース起動後にキーストアを利用可能な状態にすることもできます。 以上でキーストアの構成は完了です。続いて構成したキーストアにマスター鍵を作成します。マスター鍵の作成のためのコマンドは以下の通りです。 ADMINISTER KEY MANAGEMENT SET KEY USING TAG 'マスター鍵v1' IDENTIFIED BY oracle12c WITH BACKUP; ここでは「'マスター鍵v1'」というTAG名でマスター鍵を作成しています。TAG名には鍵が増えたときに識別できるようにわかりやすい名前を付けておいてください。 以上でマスター鍵の作成は完了です。 なお、12cでマルチテナント環境を利用している場合には、キーストアはすべてのPDBで単一のものを共有しますが、マスター鍵は各PDBで個別に持ちます。PDBで透過的データ暗号化機能を利用した場合には、PDBごとに個別にマスター鍵を作成してください。 マスター鍵が準備できると、暗号化表領域を作成できます。暗号化表領域を作成するにはCREATE TABLESPACE文に以下のようにENCRYPTION句とSTORAGE句のENCRYPTオプションのふたつを指定します。 create tablespace enctbs datafile '/opt/oracle/oradata/orcl/orclpdb/enctbs.dbf' size 10m encryption using 'aes256' default storage (encrypt); ENCRYPTION句では利用する暗号化アルゴリズムを指定します。指定できる暗号化アルゴリズムと鍵長はAES256、AES192、AES128および3DES168で、指定を省略した際のデフォルトはAES128です。 暗号化表領域を作成したら、この表領域に表や索引などのオブジェクトを作成していくと、自動的に暗号化して保存されます。 さて、デフォルトの状態ではデータベースを起動するたびにキーストアを利用可能な状態にするコマンドを発行する必要があります。しかし、自動ログインキーストア機能を利用することで、キーストアを自動的に利用可能な状態にすることもできます。 自動ログインキーストアを作成するためには以下のコマンドを発行します。 ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE '/opt/oracle/admin/orcl/wallet' IDENTIFIED BY oracle12c; このコマンドを発行すると指定したディレクトリにcwallet.ssoというファイルができ、このファイルをデータベースが参照することで、自動的にキーストアを利用可能な状態にすることができます。 「もくじ」にもどる

透過的データ暗号化機能は、Oracle Database Enterprise Editionであれば、バイナリの追加インストールなしでそのまま利用することができます。Oracle Database Standard Editionを利用している場合には、Enterprise Editionへのアップグレードが必要となります。(もちろん利用にはEnterprise...

暗号化

[第58回] 透過的データ暗号化による性能への影響

暗号化を実施しようとしたときのの最もよく聞かれるのが性能への影響です。 透過的データ暗号化の表領域暗号化の性能への影響の指標は数%です。「Advanced Securityガイド」マニュアルにも以下の記載があります。 透過的データ暗号化の正確なパフォーマンス・テストの作成には、様々な変動要素が関係します。テスト環境、テスト・ケースまたはワークロード、計測メトリックまたは方法などにより、結果は変わります。オラクル社は、考えられるすべてのシナリオに当てはまる、パフォーマンス・オーバーヘッドの具体的なパーセンテージを保証することはできません。実際に、透過的データ暗号化の多くのお客様のパフォーマンス・テストでは1桁台前半のパーセンテージが示されますが、必ずそうなるわけではありません。オーバーヘッドがそれぞれ1パーセントおよび2パーセントである顧客事例が、Oracle Technology Networkの次のURLで公開されています。 http://streaming.oracle.com/ebn/podcasts/media/12740910_ColumbiaU_120312.mp3 ちなみに、最後のURLは残念ながら英語音声です。 まず、近年(と言っても5年以上経っています)のハードウェアの進化により暗号化処理をハードウェアのチップセット内で実施できるようになりました。たとえば、IntelのCPUにはAES-NIという命令セットがあり、この命令セットを利用することでデータベースの暗号化・復号の性能は7倍から10倍に向上しているという、Intelのホワイトペーパーがあります。 さらに、表領域暗号化ではディスクI/O時に暗号化・復号処理が実施されます。つまり、ディスクI/Oを伴わない処理では性能への影響はありません。つまりディスクI/Oを少なうするようにSQLがきちんとチューニングできている環境では表領域暗号化の性能への影響を少なくすることができます。ディスクI/Oを少なくするための一般的なチューニング方法には索引の利用があります。アプリケーションで暗号化すると索引が利用できなくなるケースもありますが、表領域暗号化では、表領域上のすべてのデータを暗号化できますので、暗号化していないときと変わらず索引を利用することができます。 表領域暗号化利用時のそのほかのチューニング方法も暗号化していないときと同様です。ディスクI/Oを減らすためにデータの圧縮機能(Advanced Compression)機能を利用できます。表領域暗号化とAdvanced Compressionを同時に利用している場合、データは圧縮後に暗号化されます。データを圧縮することでディスクI/Oを少なくすることができますが、ディスクI/Oが少なくなるため、結果的に暗号化・復号するデータ量も減り、性能への影響を小さくすることができます。 同様にバッファキャッシュを大きくして、ディスクI/Oを減らすことでも暗号化の性能への影響を小さくできます。 もちろん、実際のプロジェクトごとに見ていくと暗号化の導入により特定の処理が遅くなったという問題は発生することがあります。私自身も性能が劣化したというトラブル対応に立ち会ったことが昔ありますが、どのケースでも結果としては遅くなった処理のSTATSPACKやAWRによる性能レポート(SQL実行計画)をみると、索引は作成していたが利用せず毎回ディスクに読み込みをおこなっていたなど想定外のディスクI/Oが発生していまいた。統計情報やパラメータなどで索引をきちんと利用できるように通常のSQLチューニングするだけで暗号化をおこなっていても、チューニングをおこなう前よりも処理が速くなることも多いです。体感的にディスクI/Oは発生していないだろうという時間で終わっている処理でも、実際にはストレージサーバーのキャッシュを利用していたために実際のディスクI/Oは発生していないだけで、Oracle Databaseから見るとディスク読み込みをおこなう実行計画が選択されていたケースもあります。 暗号化・復号処理がディスクI/O時に発生することが分かってれば、暗号化をおこなう前にどのような処理で影響が出そうか確認することも容易です。大量のデータの読み込み、書き込みをおこなう特にバッチ処理を中心に影響を確認し、必要に応じてディスクI/Oが最小化できるようにSQLチューニングをおこなえばよいわけです。現行システムですべての処理が想定時間内で完了している場合でも、実際には想定外のディスクI/Oが発生している処理があるかもしれません。暗号化導入時には事前にディスクI/Oが発生している処理を性能レポートから割り出しておくことが重要です。 透過的データ暗号化機能の表領域暗号化は、2007年に出荷されたOracle Database 11gR1から提供され、セキュリティ向上、コンプライアンス要件適合のために国内外含めさまざまな業種で多数利用されています。また、Oracle Cloud上のOracle Databaseでは、SEを含めすべてのパッケージ(エディション)でこの暗号化機能が有効化されています。このように広く使われている理由として、アプリケーションを書き換えなくてよいという利便性のほかに、オンライン処理・バッチ処理ともに業務への影響がでるほどの性能劣化がないこともあげられます。 「暗号化すれば性能への影響がでる」ことは事実です。しかし、ハードウェアやソフトウェアの仕組みにより、性能への影響は最小限に抑えられています。「性能をとるか安全性をとるか」ではなく、「性能を担保したうえで安全性も確保する」ことが現在ではできます。 「もくじ」にもどる        

暗号化を実施しようとしたときのの最もよく聞かれるのが性能への影響です。 透過的データ暗号化の表領域暗号化の性能への影響の指標は数%です。「Advanced Securityガイド」マニュアルにも以下の記載があります。 透過的データ暗号化の正確なパフォーマンス・テストの作成には、様々な変動要素...

暗号化

[第57回] 透過的データ暗号化機能

データベースで暗号化する機能として、Oracle DatabaseではAdvanced Security Optionで透過的データ暗号化(TDE:Transparent Data Encryption)を提供しています。 透過的データ暗号化はその名の通り、データベースがアプリケーションから透過的に自動的に暗号化して保存する機能です。アプリケーションからは透過的であるため、アプリケーションを書き換える必要はありません。アプリケーションの変更なくコンプライアンス要件などの格納データの暗号化を実現することができます。 透過的データ暗号化では、表の列単位(10gR2~)と表領域単位(11gR1~)の2つの暗号化機能を提供しています。ここでは性能への影響が少なく、多くのお客様が選択している表領域の暗号化機能を紹介します。表領域暗号化と列暗号化の違いは最後にまとめます。 表領域暗号化は、表領域全体を暗号化する機能でその表領域に保存された表、索引などのオブジェクトを自動的に暗号化することができます。また、暗号化の鍵管理もOracle Keystore(11gR2まではOracle Walletという名称)で安全に管理するための機能を提供しています。 表領域暗号化の特徴は以下の通りです。 表領域単位での暗号化 表領域内の表や索引といったオブジェクトは すべて暗号化される データブロックに対するI/Oで暗号化・復号 REDOログ、UNDO表領域、アーカイブログも暗号化される SGAのバッファキャッシュ上は暗号化されていない 暗号化してもデータサイズは増加しない 表領域暗号鍵はデータファイルのヘッダーに格納 暗号列への索引に制限なし ほとんどすべてのオブジェクトが暗号化可能 (BFILEのみ不可) 透過的データ暗号化を利用する際にデータベース管理者が管理する暗号鍵は1つだけです。この鍵をマスター鍵と呼びます。マスター鍵はOracle Keystoreとしてファイルに保存するか、暗号処理と鍵管理専用デバイスであるHSM(Hardware Security Module)に格納することができます。実際にデータを暗号化している鍵は表領域暗号鍵でマスター鍵ではこの表領域暗号鍵を暗号化しています。暗号化された表領域ごとに異なる表領域暗号鍵が作成され、データベース内に保存されます。マスター鍵はOracle KeystoreもしくはHSMとしてデータベース外部に1つだけ独立して保持されつつ、実際にデータを暗号化するための鍵は表領域単位で複数あり、データベース内で自動的に管理されるという、管理性と安全性に優れた鍵管理方式になっています。 なお、列暗号と表領域暗号の違いは以下の通りです。 列暗号はSQL発行のタイミングで暗号化・復号処理がレコード単位で実施されるので表領域暗号化と比べて性能への影響が大きくなる傾向があり、最近では一般的に表領域暗号化が利用されています。 「もくじ」にもどる    

データベースで暗号化する機能として、Oracle DatabaseではAdvanced Security Optionで透過的データ暗号化(TDE:Transparent Data Encryption)を提供しています。透過的データ暗号化はその名の通り、データベースがアプリケーションから透過的に自動的に暗号化して保存する機能です。アプリケーションからは透過的であるため、アプリケーションを書き換える...

ID管理・認証

【リコー様、IDaaS事例ご紹介】 11/30 ITmediaエンタープライズ セキュリティセミナー

11/30(木)に開催される ITmediaエンタープライズ セキュリティセミナー の東京会場に出展致します。 今回は、リコー様に弊社のクラウドのIDaaS製品であるOracle Identity Cloud Serviceの活用事例をご紹介頂きます。 また、オラクルからは、Oracle OpenWorld 2017で発表した Oracle Management and Security Cloud について紹介させて頂きます。 弊社セッション概要  -------------------------- 日時:2017年 11 月 30 日(木) セッション:A-2(12:10 - 12:40) タイトル:リコーが取り組む、クラウドのID管理とセキュリティ対策 URL:https://itmedia.smartseminar.jp/public/application/add/1659 講演者: 株式会社リコー  オフィスサービス事業本部 ワークプレイスソリューションセンター サービスプラットフォーム開発室 谷口 竜 様  日本オラクル株式会社 クラウド・テクノロジー事業統括 Cloud Platformビジネス推進本部 シニアマネージャー 大澤 清吾  講演概要: クラウド活用が加速するなか、課題となるのがセキュリティ対策とID管理です。今回は、リコー様のクラウド型のID管理(IDaaS)の取り組みについてご講演いただきます。 また、セキュリティリスクを検知する CASB や SIEM+UEBA などの対策も重要となってきています。最新動向とオラクルのソリューションもご紹介します。  -------------------------- ◇ イベント開催概要 ◇ 開催日時:2017年11月30日(木)10:00~18:30(受付 9:30~) 会場:東京コンファレンスセンター・品川 [JR山手線 品川駅港南口(東口)徒歩2分] 参加費:無料 詳細内容/ご参加のお申込み ⇒ こちら

11/30(木)に開催される ITmediaエンタープライズ セキュリティセミナー の東京会場に出展致します。 今回は、リコー様に弊社のクラウドのIDaaS製品であるOracle Identity Cloud Serviceの活用事例をご紹介頂きます。 また、オラクルからは、Oracle OpenWorld 2017で発表した Oracle Management and Security...

暗号化

[第56回] アプリケーション暗号化が有効なケースとハッシュ化

前回、アプリケーション暗号化を利用する際には、さまざまな影響があるので考慮が必要と説明しました。しかし、アプリケーション暗号化をおこなうことが有効なケースもあります。アクセス頻度が低い、一度にアクセスされるレコード数が少ない、検索条件になっていないといった条件を満たす特に重要なデータに関してはアプリケーションでの暗号化が有効です。 たとえば、ユーザーのパスワードをデータベースに格納する場合、アプリケーションの暗号化が有効です。アクセスはログイン時とパスワード変更時のみと低く、一度にアクセスするのは自分のパスワード1件だけで、パスワードをキーとして検索をされることはありません。そして、パスワード情報は重要な情報です。 クレジットカード番号やマイナンバーも暗号化すべき重要な情報ですが、請求処理や年末調整処理などのバッチで一度に大量の件数にアクセスすることがあったり、これらの番号をキーとして検索をおこなう可能性も考えられるため、アプリケーションでの暗号化が必ずしも有効とは言えません。番号をキーとする検索の例としては「あるクレジットカード番号は偽造の恐れがあるのですが、この番号での購入があったか調査してください。」という依頼への対応などが考えられます。 名前、住所、電話番号などの個人情報はアクセス頻度が高く、一度にアクセスされるレコード数が多いケースも多数考えられ、検索条件として使われることも多いのでアプリケーションでの暗号化が有効とは言えません。 クレジットカード番号やマイナンバーは、元の値を利用して処理をおこないますので、暗号化したデータを復号する必要があります。一方、パスワードは入力した値と保存された値が一致するかどうかの確認をおこなうだけで値自体を利用するわけではありません。暗号化した後の値が一致するかどうかを確認すればよいわけで、元のデータ(平文パスワード)に復号する必要はありません。さらに言ってしまうと復号できる方式で暗号化する必要がありません。復号するためには暗号鍵が必要ですが、暗号鍵の管理にはコストがかかります。そのためこのような元の値を利用しないようなケースでは、暗号化したデータを復号できる可逆性のある暗号化ではなく、元のデータを判別できないデータにした後、元のデータに戻せない不可逆性のハッシュ化を利用することができます。 Oracle Databaseでは、DBMS_CRYPTOパッケージでハッシュ化をおこなうためのHASHファンクションを提供しています。 利用できるハッシュアルゴリズムはOracle Databaseのバージョンにより異なりますので詳細はマニュアルを参照してください。 古いハッシュアルゴリズムはすでに危殆化しているものもありますので、可能であればCRYPTREC暗号リストに載っているハッシュ関数を利用することを推奨します。 ハッシュ化のためのファンクションの例は以下の通りです。 create or replace package myHash as function hash(var in varchar2) return raw; end; / create or replace package body myHash as myType number := DBMS_CRYPTO.HASH_SH256; function hash(var in varchar2) return raw is begin return dbms_crypto.hash(src => UTL_I18N.STRING_TO_RAW (var, 'AL32UTF8'), typ => myType); end; end; / 作成したファンクションを利用してハッシュ化をおこなう例は以下の通りです。 SQL> select myHash.hash('Password') from dual; MYHASH.HASH('PASSWORD') -------------------------------------------------------------------------------- E7CF3EF4F17C3999A94F2C6F612E8A888E5B1026878E4E19398B23BD38EC221A 実際にユーザー名とパスワードを格納するためのAUTHTABLE表の例は以下の通りです。パスワードを格納数列は今回はハッシュアルゴリズムにSHA-256を利用しているためデータ型をRAW(256)で定義します。 create table authtable ( username varchar2(32), password raw(256)); サンプルデータとして、ユーザー名user01、パスワードpass_user01というレコードを挿入します。 insert into authtable values ('user01', myHash.hash('pass_user01')); 格納されたパスワードはハッシュ化されている(元のデータが推測できない)のが確認できます。 SQL> select * from authtable; USERNAME -------------------------------- PASSWORD -------------------------------------------------------------------------------- user01 547CDB4C2B0954F3534EB032329EAC8D33C050870455566BB9579D296D79A424 アプリケーションからは、たとえば以下のようなSQL文を発行してユーザー認証を実施します。 select username from authtable where username='ユーザー名' and password = myHash.hash('パスワード'); ユーザー名とパスワードが正しい場合にはユーザー名が戻り、ユーザー名とパスワードが間違っている場合にはレコードが戻りません。 SQL> select username from authtable where username='user01' and password = myHash.hash('pass_user01'); USERNAME -------------------------------- user01 SQL> select username from authtable where username='user01' and password = myHash.hash('wrong_password'); レコードが選択されませんでした。 このユーザー認証ロジックをアプリケーションに組み込むときには、リテラルの連結でプログラムを組み込まず、必ずバインド変数を利用するようにしてください。リテラルを連結してSQL文を生成するとSQLインジェクション攻撃が可能な脆弱なアプリケーションとなってしまいます。 バインド変数を利用するSQLインジェクションが起こらない実装例 String sqltext = "select username from authtable where username = ? and password = myHash.hash(?)"; PreparedStatement pstmt = conn.prepareStatement(sqltext); pstmt.setString(1, v_username); pstmt.setString(2, password); ResultSet rset = pstmt.executeQuery(); リテラルの連結を利用したSQLインジェクションが起こってしまう実装例 String sqltext = "select username from authtable where username = '" + v_username + "' and password = myHash.hash('" + v_password + "')"; ResultSet rset = stmt.executeQuery(sqltext); リテラルの連結を利用したSQLインジェクションが起こってしまう例ではアプリケーションからユーザー名(v_username)に「user01' --」、パスワード(v_password)に「a」(何でもよい)を指定すると、sqltextは以下のようになります。 select username from authtable where username = 'user01' --' and password = myHash.hash('a') ここで「--」以下はコメントとして無視されますので、結果としてuser01というユーザー名が戻ります。user01だけでなく、ユーザーが存在すれば任意のユーザーでユーザー名が戻りますので、結果として任意のユーザーに成り済まされて認証が成功してしまいます。 アプリケーションの認証部分に脆弱性があると、結果として任意のユーザーに成り済まされて、正規のユーザーとして自由にアプリケーションが利用されてしまいますので注意が必要です。 今回は場合によってはアプリケーションの暗号化が向いているケースがある例、また暗号化ではなくハッシュ化のほうが運用が簡単でより安全なケースとOracle Databaseでのハッシュ化の実装例を紹介しました。アプリケーションでの暗号化やハッシュはOracle Databaseの機能を利用しなくても、JAVAなどのプログラム側で実装したり、外部製品と組み合わせたりしても実現可能です。 今後紹介予定のデータベースでの暗号化機能と組み合わせて利用するとより安全にデータを保護することができますので、データベース設計の参考にしてください。 「もくじ」にもどる  

前回、アプリケーション暗号化を利用する際には、さまざまな影響があるので考慮が必要と説明しました。しかし、アプリケーション暗号化をおこなうことが有効なケースもあります。アクセス頻度が低い、一度にアクセスされるレコード数が少ない、検索条件になっていないといった条件を満たす特に重要なデータに関してはアプリケーションでの暗号化が有効です。たとえば、ユーザーのパスワードをデータベースに格納する場...

暗号化

[第55回] DBMS_CRYPTOパッケージ

アプリケーションで暗号化してからデータベースに格納する方法として、Oracle DatabaseではDBMS_CRYPTOというPL/SQLパッケージを用意しています。 なお、このDBMS_CRYPTOパッケージへのアクセス権限が制限されています。EXECUTE ANY PROCEDUREシステム権限やこの権限を含むDBAロールを付与されているユーザー、例えばSYSTEMユーザーであってもデフォルトの状態ではDBMS_CRYPTOパッケージを利用できません。パッケージ実行のためのオブジェクト権限を明示的に付与する必要があります。 DBAロールを持っているユーザーでも、デフォルトの状態ではDBMS_CRYPTOパッケージにはアクセスできないことが確認できます。 SQL> select role from session_roles where role='DBA'; ROLE -------------------------------------------------------------------------------- DBA SQL> desc dbms_crypto; ERROR: ORA-04043: オブジェクト"SYS"."DBMS_CRYPTO"は存在しません。 SYSユーザーでデータベースに接続し、DBMS_CRYPTOパッケージに対するオブジェクト権限の付与状況を調べても、誰にも付与されていないのが確認できます。 SQL> select grantee, privilege from dba_tab_privs where table_name='DBMS_CRYPTO'; レコードが選択されませんでした。 オブジェクト権限を明示的に付与することでユーザーはDBMS_CRYPTOパッケージを利用できるようになります。 SQL> grant execute on dbms_crypto to puku; 権限付与が成功しました。 SQL> select grantee, privilege from dba_tab_privs where table_name='DBMS_CRYPTO'; GRANTEE -------------------------------------------------------------------------------- PRIVILEGE ---------------------------------------- PUKU EXECUTE 次にDBMS_CRYPTOパッケージを利用して、暗号化/復号用のファンクションを作成します。 create or replace package myCrypto as function encrypt(var in varchar2) return raw; function decrypt(var in raw) return varchar2; end; / create or replace package body myCrypto as myKey VARCHAR2(32) := '12345678901234567890123456789012'; myType NUMBER := DBMS_CRYPTO.ENCRYPT_AES256 + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5; rawKey RAW(32) := UTL_I18N.STRING_TO_RAW(myKey, 'AL32UTF8'); function encrypt (var in varchar2) return raw is begin return dbms_crypto.encrypt(src => UTL_I18N.STRING_TO_RAW (var, 'AL32UTF8'), typ => myType, key => rawKey); end; function decrypt (var in raw) return varchar2 is begin return UTL_I18N.RAW_TO_CHAR(dbms_crypto.decrypt(src => var, typ => myType, key => rawKey), 'AL32UTF8'); end; end; / 暗号化、復号は以下のように実施します。 SQL>select myCrypto.encrypt('サンプルデータ') from dual; MYCRYPTO.ENCRYPT('サンプルデータ') -------------------------------------------------------------------------------- 5EFC472AA972468134144B2F9D679335F8AFDF7053E87DAE172CA56EBCABDAF8 SQL> select myCrypto.decrypt('5EFC472AA972468134144B2F9D679335F8AFDF7053E87DAE172CA56EBCABDAF8') from dual; MYCRYPTO.DECRYPT('5EFC472AA972468134144B2F9D679335F8AFDF7053E87DAE172CA56EBCABDA -------------------------------------------------------------------------------- サンプルデータ 暗号化したデータはRAW型ですので、格納する表の定義は文字列(VARCHAR2)型ではなく、RAW型で定義しなおす必要があります。 また、暗号化されたデータはブロック暗号アルゴリズムで暗号化されているため16バイト単位で切り上げられ、データ長が長くなることが確認できます。 SQL> select lengthb('サンプルデータ') from dual; LENGTHB('サンプルデータ') ------------------------- 21 SQL> select utl_raw.length(myCrypto.encrypt('サンプルデータ')) from dual; UTL_RAW.LENGTH(MYCRYPTO.ENCRYPT('サンプルデータ')) -------------------------------------------------- 32 例えば暗号化前の表定義が、以下のようにVARCHAR2(30)だとします。 create table test_noenc ( c1 varchar2(30)); このデータベースのキャラクタセットはAL32UTF8であるため、この列には10文字のデータを格納できます。日本語などマルチバイト文字の場合、10文字は暗号化ファンクションの中ではAL32UTF8キャラクタセットに変換して扱われますので、1文字が3バイトとなり、30バイトとなり、16バイト単位で切り上げられますので、以下のようにRAW(32)と定義する必要があります。ここではデータベースのキャラクタセットがAL32UTF8と1文字3バイトの文字コードのためサイズの差はあまり出ませんでしたが、SJISやEUCなど1文字2バイトの文字コードを利用している場合には、データサイズに差が出がちですので注意が必要です。 create table test_enc ( c1 raw(32)); 暗号化していない表に対しては通常のINSERT文を発行できますが、暗号化した表にINSERT文を発行する際には暗号化ファンクションをかませる必要があります。 insert into test_noenc values ('abc'); insert into test_noenc values ('あ'); insert into test_noenc values ('あいうえおかきくけこ'); insert into test_enc values (myCrypto.encrypt('abc')); insert into test_enc values (myCrypto.encrypt('あ')); insert into test_enc values (myCrypto.encrypt('あいうえおかきくけこ')); それぞれの表を検索してみます。暗号化された表ではデータ長が長くなってしまっているのが確認できます。 SQL> select * from test_noenc; C1 ------------------------------ abc あ あいうえおかきくけこ SQL> select * from test_enc; C1 ---------------------------------------------------------------- AB6B52A0228A71BCFC44232CA3E47640 71B09B2A35A1CEEC85706FF87138056C 147BE2B36BD8D95B060A17DA9DC781AE8DE3E9F6ECAECBE486CEEEBFA104759F 暗号化されていないデータを暗号化された表から取り出す場合には、復号ファンクションをかませます。 SQL> select myCrypto.decrypt(c1) from test_enc; MYCRYPTO.DECRYPT(C1) -------------------------------------------------------------------------------- abc あ あいうえおかきくけこ DBMS_CRYPTOパッケージの使い方は以上です。 アプリケーションで暗号化してからデータベースに格納する方法としては、DBMS_CRYPTOパッケージを利用するほかにプログラム側で暗号化ロジックを組んだり、暗号化パッケージ製品を利用したりする方法が考えられます。ただし、どの方法を利用するにしても共通して以下の注意点があります。 暗号化によりデータ型やデータサイズが変わる 暗号化したデータはバイナリ型になりますので表定義を変更する必要があります。バイナリ型を文字列として扱おうとすると、データ長がさらに長くなったり、変換のための追加の処理をしなければならなかったり、データが壊れてしまう可能性もあります。文字列型に暗号化する製品もあるかもしれませんが、その場合は利用している暗号アルゴリズムが電子政府推奨暗号リスト(CRYPTREC)やISO/IEC 18033で定義されている標準的で安全性が確認されているものから外れてしまう可能性があります。 アプリケーションの書き換えが必要 暗号化されたデータを扱うプログラムロジックのすべてに暗号化/復号のロジックを埋め込む必要があります。もし埋め込みを忘れてしまうとデータが破壊されてしまう可能性もあります。 索引の利用に制限(チューニングが困難) 暗号化した列に索引を作成することは可能ですが、この索引は完全一致検索でしか利用できません。部分一致検索で索引を利用しようとすると結果0件となりますし、範囲検索に利用されてしまうと暗号化した後のデータで範囲検索されますので、全く関係ない結果が戻ってしまいます。また、今回利用したファンクションでは、同じ値を暗号化すると毎回暗号化された結果は同じになりますが、より安全に運用するために毎回出力される結果が変わるような(SALTを付けた)ファンクションを作成した場合、完全一致検索でも索引は利用できなくなります。 参考までにSALTを付けた暗号化ファンクションは以下のように定義できます。 create or replace package myCrypto2 as function encrypt(var in varchar2) return raw; function decrypt(var in raw) return varchar2; end; / create or replace package body myCrypto2 as myKey VARCHAR2(32) := '12345678901234567890123456789012'; myType NUMBER := DBMS_CRYPTO.ENCRYPT_AES256 + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5; rawKey RAW(32) := UTL_I18N.STRING_TO_RAW(myKey, 'AL32UTF8'); retval VARCHAR2(64); function encrypt (var in varchar2) return raw is begin return dbms_crypto.encrypt(src => UTL_I18N.STRING_TO_RAW (dbms_random.string('P',8) || var, 'AL32UTF8'), typ => myType, key => rawKey); end; function decrypt (var in raw) return varchar2 is begin retval := UTL_I18N.RAW_TO_CHAR(dbms_crypto.decrypt(src => var, typ => myType, key => rawKey), 'AL32UTF8'); return substr(retval,9,length(retval)); end; end; / 以下の例では3回暗号化していますが、それぞれ異なる暗号化データとなり、異なる暗号化データを復号すると同じ元の平文に戻ります。 SQL> select myCrypto2.encrypt('あいうえお') from dual; MYCRYPTO2.ENCRYPT('あいうえお') -------------------------------------------------------------------------------- 141E841C942C339E9D088E9B173B165BA33C45401E66EE17DF2959E06C7E135E SQL> / MYCRYPTO2.ENCRYPT('あいうえお') -------------------------------------------------------------------------------- 6E4B6F039D9406AC57AF266B515AEA50421C8EAB4BF5D09F2AC774E502D1FC7D SQL> / MYCRYPTO2.ENCRYPT('あいうえお') -------------------------------------------------------------------------------- 500C87B6B47244C7D47DAD2C88243E2C2F2F9049B70192129F0D8C0E3163018F SQL> select myCrypto2.decrypt('141E841C942C339E9D088E9B173B165BA33C45401E66EE17DF2959E06C7E135E') from dual; MYCRYPTO2.DECRYPT('141E841C942C339E9D088E9B173B165BA33C45401E66EE17DF2959E06C7E1 -------------------------------------------------------------------------------- あいうえお SQL> select myCrypto2.decrypt('6E4B6F039D9406AC57AF266B515AEA50421C8EAB4BF5D09F2AC774E502D1FC7D') from dual; MYCRYPTO2.DECRYPT('6E4B6F039D9406AC57AF266B515AEA50421C8EAB4BF5D09F2AC774E502D1F -------------------------------------------------------------------------------- あいうえお SQL> select myCrypto2.decrypt('500C87B6B47244C7D47DAD2C88243E2C2F2F9049B70192129F0D8C0E3163018F') from dual; MYCRYPTO2.DECRYPT('500C87B6B47244C7D47DAD2C88243E2C2F2F9049B70192129F0D8C0E31630 -------------------------------------------------------------------------------- あいうえお データベースアクセスによる情報漏洩は防げても、不正書換、削除には対応できない 暗号化後にデータベースに格納しておけば、データベース管理者などがSELECT文でデータを見ようとしても、たしかに暗号化後のデータしか見ることができません。しかし、見えないだけであって、データにアクセスできないわけではありません。書き換えることはできるので、データ破壊を防ぐことはできません。また、データが破壊されているかどうかの確認は復号できるかどうか確認しないとわからないため、値の確認やデータパッチなどの管理操作のコストも増大します。 (2017/11/7追記) 個人情報保護委員会の出している「個人情報の保護に関する法律についてのガイドライン」でも『「個人に関する情報」とは、… (中略) … 暗号化等によって秘匿化されているかどうかを問わない』と暗号化してあっても個人情報は個人情報でありアクセス制御などの安全管理措置を講じなければならないと明記されています。暗号化だけでは不正書き換え、削除には対応できないために、暗号化されていてもアクセス制御が必要ということもこの記述の理由のひとつだといえます。 鍵管理・配布が複雑 暗号化パッケージを利用する場合には、暗号鍵の管理を自分でおこなわなくてはなりません。今回作成したファンクションでは暗号鍵をパッケージ内に記載しています。そのため、USER_SOURCEやDBA_SOURCEなどを以下のように検索すると、暗号鍵が見えてしまいます。 select text from user_source where name='MYCRYPTO' and type='PACKAGE BODY' order by line; DBMS_DDLパッケージのWRAPファンクションやWRAPEDプロシージャを利用することで、パッケージのソースを分かりにくく(不明瞭化)することができますので、これらの機能と併せて利用する必要があります。なお、不明瞭化したソースは元に戻すことができませんので、別でパッケージのソースを保存しておく必要があります。 また、暗号鍵の変更をおこなう仕組みがないため、暗号鍵の変更をおこなう方法を別途考えておく必要があります。 外部の暗号化製品を利用する場合、暗号鍵管理や変更などの機能があるものがあるかもしれませんが、これらの製品を利用する場合、各アプリケーションに暗号鍵を含む製品を配布したり、暗号鍵やロジック自体は1か所のサーバーで管理している場合でも、暗号化・復号ロジックにアクセスするための認証情報を各アプリケーションに配布しなければならないため、管理コストはアプリケーション数分だけ増大してしまいます。 アプリケーションでの暗号化には様々な注意点があります。利用する際にはこれらの注意点を考慮して設計・設定してください。 「もくじ」にもどる      

アプリケーションで暗号化してからデータベースに格納する方法として、Oracle DatabaseではDBMS_CRYPTOというPL/SQLパッケージを用意しています。 なお、このDBMS_CRYPTOパッケージへのアクセス権限が制限されています。EXECUTE ANY PROCEDUREシステム...

暗号化

[第54回] データベース格納データの暗号化の方式

Oracle Databaseに格納するデータを暗号化するために方式としては、以下の3つが挙げられます。 アプリケーションで暗号化してからデータベースに格納する方式 データベースの暗号化機能を利用する方式 OSやストレージなどデータベースより下位レイヤの機能を利用して暗号化する方式 1. アプリケーションで暗号化してからデータベースに格納する方式 暗号化APIなどを利用して、アプリケーションでデータを暗号化してから、データベースに格納する方式です。データベースには暗号化された状態でデータは格納され、データベース問い合わせでは暗号化されたデータが戻り、アプリケーション側で復号します。 2. データベースの暗号化機能を利用する方式 Oracle DatabaseのEnterprise Editionの有償オプションであるOracle Advanced Securityの透過的データ暗号化(TDE:Transparent Data Encryption)機能を利用して暗号化する方式です。透過的データ暗号化機能の特徴は、その名の通りアプリケーションに変更を加えることなく格納データを暗号化することができることです。アプリケーションからは通常のSQL問い合わせを発行するだけで、データベースが内部的にデータを暗号化して格納し、暗号化されたデータを透過的に復号してアプリケーションに戻します。 3. OSやストレージなどデータベースより下位レイヤの機能を利用して暗号化する方式 OS、ファイルシステム、ストレージ機器などの暗号化機能を利用します。ストレージの暗号化機能を利用する場合、OSからのファイルアクセスに書き込むときに自動的に暗号化され、ファイルシステムから読み込む時に透過的に暗号化されたデータが復号されます。   それぞれの暗号化方式で対応できる脅威と利用時の注意点は以下の通りです。 方式 アプリケーションで暗号化してからデータベースに格納 データベースの暗号化機能を利用 ストレージの暗号化機能を利用 実装例 カスタムアプリ開発 暗号化製品利用 データベース機能 (TDE表領域暗号化) ストレージ機能 アプライアンス製品 対応できる脅威 ストレージ機器の盗難 データファイルの盗難 データベースへの直接アクセス ストレージ機器の盗難 データファイルの盗難 ストレージ機器の盗難 利用時の注意点 暗号化によりデータ長やデータ型が変わる アプリケーションの書き換えが必要 索引の利用に制限 (チューニングが困難) 問い合わせごとに暗号化/復号処理が毎回おこなわれるため、暗号化列数が多い場合や戻り行数が多い場合には負荷大 データベースアクセスによる情報漏洩は防げても、不正書換、削除には対応できない 鍵管理・配布が複雑 ファイルI/O時に暗号化/復号がおこなわれるため、OSメモリ上のデータは暗号化されていない OSからは元のデータが見える OS経由でバックアップすると暗号化されない 暗号化単位により余計なI/Oや暗号化/復号処理が発生する可能性 問題発生時の切り分けが困難かつ、回避策として暗号化製品を利用しない運用をお願いする可能性あり   アプリケーションで暗号化しておけば、データベースのデータを参照されてもアプリケーション経由でなければ、暗号化されたデータしか見えないので最も安全という側面は確かにあります。しかし、アプリケーションによる暗号化はシステム変更への影響が大きく、暗号化をおこなうことにより特別なSQLチューニングが必要になったり、チューニングができなくなったりします。そのため、実際に利用する際には対象範囲を狭める必要があります。暗号化したい情報でも検索条件として利用されている場合、暗号化できないケースもあります。 OSやストレージなどのデータベースより下位のレイヤで暗号化しておけば、データベースのデータもファイルとして保存しているデータも同じ方式で暗号化をおこなうことができます。しかし、OSからファイルを参照すると元のデータが見えてしまうため、対応できる脅威の範囲が小さいことに注意が必要です。近年のサイバー攻撃での侵入はOSユーザーを乗っ取る、成り済ますケースが多いです。このような攻撃はOSファイルを参照されてしまいますので脅威に対応できません。 データベースを暗号化するためには、やはりデータベースの機能を利用するのがお勧めです。 「もくじ」にもどる          

Oracle Databaseに格納するデータを暗号化するために方式としては、以下の3つが挙げられます。 アプリケーションで暗号化してからデータベースに格納する方式 データベースの暗号化機能を利用する方式 OSやストレージなどデータベースより下位レイヤの機能を利用して暗号化する方式 1. アプリケーションで暗号化してからデータベースに格納する方式 暗号化APIなどを利用して、アプリケーションでデータを暗号化し...

データベースセキュリティ

明日登壇します。DBSC秋の臨時セミナー ~「ランサムウエアとDBセキュリティ」~

10/17(火) に、データベース・セキュリティ・コンソーシアム (DBSC)の秋の臨時セミナーが開催されます。 日本オラクルからは、DBSC会員企業によるソリューション紹介とパネルディスカッションにで登壇いたします。   弊社のソリューション紹介は、「データベース運用とセキュリティ対策の自動化を実現する最新ソリューション」というタイトルで、 Oracle OpenWorld 2017で発表された自律型データベースや様々なログを収集し、機械学習を活用したセキュリティ脅威の検知と自動対処を実現する Oracle Management and Security Cloud に中心にご紹介します。 ご興味のある方は、是非ご参加下さい。        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━         <データベース・セキュリティ・コンソーシアム(DBSC)主催>                             DBSC秋の臨時セミナー           ~ 「ランサムウエアとDBセキュリティ」 ~       [日時] 2017年10月17日(火)  13:00~17:00       [URL]  http://www.db-security.org/seminar/20171017.html       [会場] 東京電機大学(東京千住キャンパス)1号館2階「1205セミナー室」       ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━   DBSC秋の臨時セミナーを以下のとおり開催いたします。  世界中を震撼させた「WannaCry」や「Petya」をはじめランサムウエアの感染により業務に支障が出る影響が多発し話題となっております。ランサムウェアの対策やDBへの対策についてセミナーを開催いたします。 DBSC会員企業だけではなく、一般の方もご参加いただけますので、ぜひお申込みください。   ※本イベントご参加で、(ISC)2認定資格保持者様のCPEクレジット(2p)が取得可能です   ///// セミナー概要 ////////////////////////////////////////////////////////   ■日程 / 2017年10月17日(火) 13:00 ~ 17:00(受付12:30~) ■参加費 / 無料 ■定員 / 100名 ■会場 / 東京電機大学(東京千住キャンパス)1号館2階「1205セミナー室」              https://www.dendai.ac.jp/access/tokyo_senju.html ■内容 /  13:00~13:10 開会挨拶 DBSC会長:安田浩氏 (東京電機大学 学長)    13:10~14:10 基調講演「情報セキュリティ脅威のいま」               新井 悠 氏(トレンドマイクロ株式会社) 2017年上半期に発生した最も大きな情報セキュリティ事案である、5月の「WannaCry 」と6月の「Petya(別名:NotPetya、GoldenEye、など)」という2種のランサムウェアの広範な拡散による被害について解説し、現在の脅威の動向について詳解する。   14:10~15:10 DBSC会員企業によるソリューション紹介                 レック・テクノロジー・コンサルティング株式会社                  日本オラクル株式会社                  株式会社メトロ 15:10~15:25 休憩 15:25~16:55 パネルディスカッション        パネラー   :新井 悠 氏                DBSC 安田浩 氏、大澤清吾 氏、吉岡道明 氏        モデレーター : 西本逸郎 氏 16:55~17:00 閉会挨拶               DBSC事務局長:西本逸郎氏 (株式会社ラック)       ~~ 時間は、若干前後する場合もございますこと、ご了承ください ~~  

10/17(火) に、データベース・セキュリティ・コンソーシアム (DBSC)の秋の臨時セミナーが開催されます。 日本オラクルからは、DBSC会員企業によるソリューション紹介とパネルディスカッションにで登壇いたします。  弊社のソリューション紹介は、「データベース運用とセキュリティ対策の自動化を実現する最新ソリューション」というタイトルで、Oracle...

OpenWorld 2017: Oracle Management and Security Cloud (SIEM / UEBA)

先日のBlogで紹介した  10/4(火)の Oracle OpenWorld 2017 の Larry Ellison の Keynoteで「Oracle Management and Security Cloud」が発表されました。 講演では、データ漏洩事件が継続的に発生しており、その対抗措置として、セキュリティ対策とデータベース運用の自動化によるデータ漏洩防止が重要と解説してました。 この実現のために、重要な点をして以下の2点紹介しました。 Oracle Autonomous Database :パッチを即座に適用する自動的なデータベース Oracle Security Monitoring and Analytics Cloud Service: クラウド、オンプレミス区別なく、かつ、他社も含めたさまざまなDB, OS, アプリケーション等からシステム運用に関わるさまざまなログを収集し、機械学習によって不正ログインやマルウェアなどの脅威を自動的に検出・対処 Oracle Security Monitoring and Analytics Cloud Service の特長は、以下になります。 完全かつ統合されたクラウド型のシステム 1つのシステムで運用とセキュリティに関するあらゆるデータの監視、管理、分析 オンプレミス、クラウド両方の様々なログに対応 オンプレミス:ネットワーク(Firewall, Proxy, ルータ, VPN)、OS(Linux, Solaris, AIX, Windows)、ミドルウェア(Weblogic/JBOSS)、データベース(Oracle/DB2/SQL Server/Postgre/MongoDB ) など クラウドサービス(Oracle, AWSなど) 機械学習(Machine Learning) 機械学習ベースのシステムがデータの異常やセキュリティ脅威を発見  自動対処 リアルタイムのセキュリティ対処のための自動化された運用ワークフロー   講演内容は、On Demand Videos から視聴することができます。 また、本件については、プレスリリース「Oracle Announces Industry’s First Cloud-Native, Intelligent Security and Management Suite」を出しております。この中では、Oracle Identity Security Operations Center(Identity SOC) や、Oracle CASB Cloud Serviceのアップデートについても紹介しておりますので、こちらもあわせて確認下さい。

先日のBlogで紹介した  10/4(火)の Oracle OpenWorld 2017 の Larry Ellison の Keynoteで「Oracle Management and Security Cloud」が発表されました。 講演では、データ漏洩事件が継続的に発生しており、その対抗措置として、セキュリティ対策とデータベース運用の自動化によるデータ漏洩防止が重要と解説してました。 この実現の...

ID管理・認証

[第53回] 外部パスワードストア

第52回ではバッチファイルにパスワードを記載せずにデータベースに接続する機能としてOS認証を紹介しましたが、Oracle Databaseでは認証時にユーザー名/パスワードを指定せずに接続する機能としてもうひとつ外部パスワードストア機能があります。 外部パスワードストア機能を利用すると下記のようにユーザー名/パスワードを指定せずにデータベースに接続することができます。 [puku@panca ~]$ sqlplus /@orclpdb SQL*Plus: Release 12.2.0.1.0 Production on 木 9月 28 09:26:43 2017 Copyright (c) 1982, 2016, Oracle. All rights reserved. 最終正常ログイン時間: 水 9月 27 2017 21:05:25 +09:00 Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production に接続されました。 SQL> show user ユーザーは"APP1_RONLY"です。 SQL> OS認証と違うのは事前に指定した任意のユーザーで接続でいきることです。また、OS認証と外部パスワードストア機能が両方設定されている場合には、外部パスワードストアによる認証が優先されます。ユーザー名/パスワードを明示的に指定した場合には、OS認証よりも外部パスワードストアによる認証よりも、明示的に指定したユーザー名/パスワードによる認証が優先されます。 外部パスワードストアの実体はWalletと呼ばれる認証情報を暗号化・パスワードで保護して安全に格納するPKCS#12という標準フォーマットのOSファイルです。このWalletの場所をsqlnet.oraに記載するのですが、OSユーザーごとに個別のWalletを利用ために、sqlnet.oraをOSユーザーごとに分ける必要があります。そのためにはOSのTNS_ADMIN環境変数で利用するsqlnet.oraファイルを格納するディレクトリを指定する必要があります。 export TNS_ADMIN=/home/puku/tnsadmin TNS_ADMIN環境変数を指定すると、いままでデフォルトの$ORACLE_HOME/network/admin以下を参照していたネットワーク関連のファイルを指定したディレクトリを参照するようになりますので、sqlnet.oraファイルだけでなく、tnsnames.oraファイルもこのフォルダに作成する必要があります。 tnsnames.oraファイルに接続したいデータベースの接続情報を、sqlnet.oraファイルに外部パスワードストアの利用のための以下の設定をおこないます。 WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /home/puku/wallet))) SQLNET.WALLET_OVERRIDE = TRUE Walletを配置するディレクトリを指定したら、Walletを作成します。 Walletの操作にはmkstoreコマンドを利用します。Walletを作成するには以下のコマンドを発行します。 mkstore -wrl <Walletを作成するディレクトリ> -create [puku@panca ~]$ mkstore -wrl /home/puku/wallet -create Oracle Secret Store Tool: バージョン12.2.0.1.0 Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved. パスワードの入力: ← Walletのパスワードを入力 パスワードの再入力: ← Walletのパスワードを再入力 [puku@panca ~]$ コマンドが成功すると指定したディレクトリにWallet本体(ewallet.p12)と自動ログインウォレット(cwallet.sso)が自動的に作成されます。 [puku@panca ~]$ ls -l /home/puku/wallet 合計 8 -rw-------. 1 puku users 194 9月 27 20:45 2017 cwallet.sso -rw-------. 1 puku users 0 9月 27 20:45 2017 cwallet.sso.lck -rw-------. 1 puku users 149 9月 27 20:45 2017 ewallet.p12 -rw-------. 1 puku users 0 9月 27 20:45 2017 ewallet.p12.lck [puku@panca ~]$ Walletが作成されたら、Walletにデータベースへの接続情報を追加します。 以下のコマンドを発行します。 mkstore -wrl <Walletを作成したディレクトリ> -createCredential <接続文字列> <DBユーザー名>   [puku@panca ~]$ mkstore -wrl /home/puku/wallet -createCredential orclpdb app1_ronly Oracle Secret Store Tool: バージョン12.2.0.1.0 Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved. コマンド・ラインでシークレット/パスワードが欠落しています シークレット/パスワード入力: ← DBユーザーのパスワードを入力 シークレット/パスワード再入力: ← DBユーザーのパスワードを再入力 ウォレット・パスワードを入力してください: ← Walletのパスワードを入力 [puku@panca ~]$ 以上で外部パスワードストアを利用する準備は完了です。 あとはデータベースにユーザー名/パスワードを指定せずに接続すると事前に指定したユーザーでデータベースに接続できます。 [puku@panca ~]$ sqlplus /@orclpdb SQL*Plus: Release 12.2.0.1.0 Production on 水 9月 27 21:05:25 2017 Copyright (c) 1982, 2016, Oracle. All rights reserved. 最終正常ログイン時間: 水 9月 27 2017 20:58:03 +09:00 Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production に接続されました。 SQL> show user ユーザーは"APP1_RONLY"です。 それぞれのデータベース(接続文字列)ごとに作成できる事前定義の接続設定はひとつですが異なるデータベース(接続文字列)に対しては別のユーザーで接続設定を定義することができます。前回紹介したOS認証と同じくOSにデータベースへの接続の認証を移譲する機能であるため、OSのアカウント管理がより重要になり、かならずしもセキュリティ向上につながるわけではありませんが、バッチスクリプトにデータベースのユーザー名/パスワードを記載しないで済み、かつデータベースユーザー名を自由に指定できるためOS認証よりも使い勝手が良い機能です。バッチスクリプトにパスワードが記載されている場合にはこの機能の利用も検討してみてください。 「もくじ」にもどる

第52回ではバッチファイルにパスワードを記載せずにデータベースに接続する機能としてOS認証を紹介しましたが、Oracle Databaseでは認証時にユーザー名/パスワードを指定せずに接続する機能としてもうひとつ外部パスワードストア機能があります。 外部パスワードストア機能を利用すると下記のようにユーザー名/パスワードを指定せずにデータベースに接続することができます。 [puku@panca...

ID管理・認証

Oracle OpenWorld 2017 みどころ (セキュリティ)

いよいよ来週、Oracle OpenWorld 2017が開催されます。 セキュリティ関連では、お客様の活用事例の最新製品紹介やEU GDPR関連のセッションなど多くが開催されます。 ここでは、データベースセキュリティ、ID管理(IDaaS)、CASB関連のおすすめセッションをご紹介します。 現地に行かれる方は是非、ご参加ください。 また、すべてのセキュリティ関連のセッションについては、以下のURLを確認ください。    - セキュリティ関連のセッション一覧(セッション、デモ、ハンズオン)   ■ 10/2(月) 時間・会場・ID セッション名 セッション概要 13:15 - 14:00 Moscone West - Room 3011 CON6571 Cybersecurity and Compliance in 2017: Database Security Is Business-Critical データベースセキュリティの最新動向として、2018年5月25日に施行されるEUの一般データ保護規制(GDPR)、サイバーセキュリティのトレンド、クラウドへの移行によるセキュリティ管理策の変化などを紹介します。また、最新のアセスメントツールやセキュリティ機能もご紹介します。 12:15 - 13:00 Moscone South - Room 313 CON6303 How Safe Am I? Choosing the Right Security Tool for the Job ネットワークスキャナ、動的・静的解析ツール、ファジングツールなど様斬なセキュリティツールがありますが、どのツールが最適かを判断することは容易ではありません。間違った選択は無駄な結果や「誤検出」を解消するために過度な負担が発生します。本セッションでは、様々なセキュリティツールの適切な選択方法と、最も効果的なツールを使用し、社内およびクラウドでのセキュリティ対策の評価方法についてご紹介します。 15:15 - 16:00 Moscone West - Room 3007 CON4597 Modernizing and Securing Financial Sector Applications in the Cloud with Oracle UBI銀行は、Oracle Identity Security Operation Center (Identity SOC) フレームワークを使用して、包括的なセキュリティ・モデルを作成しています。 UBIがGDPR要件をオラクルのテクノロジを使用しどのように対応したかをご紹介します。また、Oracle CASB Cloud ServiceとOracle Identity Cloud Serviceによって、安全なクラウド適用プロセスを開始する際のIdentity SOC フレームワークの活用をご紹介します。 17:45 - 18:30 Moscone West - Room 3007 CON7080 Transform Your Customer Experience with Consumer Identity Access Management 現代の消費者中心のビジネス環境では、優れた顧客体験が競争優位性と収益性の鍵です。本セッションでは、顧客のIDアクセス管理を使用した顧客事例をご紹介します。顧客のIDアクセス管理は、世界中の何千ものデジタルビジネスを変えてきたアイデンティティ管理市場の急速に成長している領域です。   ■ 10/3(火)   時間・会場・ID セッション名 セッション概要 11:30 - 12:15 Moscone West - Room 3007 CON7072 Give Digital Transformation a Boost with Modern Cloud-Based Identity Management デジタルトランスフォーメーションは、企業がビジネス上の競争力を維持するための鍵です。しかし、多くのデジタルトランスフォーメーションプロジェクトは、不十分または時代遅れのID・アクセス管理の導入のために失敗します。本セッションでは、Oracle Identity Cloud Serviceをどのように利用し、将来計画を聞くことができます。また、Oracle Identity Cloud Serviceの最新機能についてもご紹介します。 11:30 - 12:15 Marriott Marquis (Yerba Buena Level) - Salon 12 CON7064 Machine-Learning-Based Analysis to Manage Cybersecurity Risks 標的型攻撃やゼロデイ攻撃が広まるにつれ、ルールベースの防御だけでは対処は困難です。侵入されることを前提に、通常の業務と異常な活動を識別する必要があります。本セッションでは、サイバーセキュリティ対策として機械学習を活用したSIEMとCASBのソリューションをご紹介します 15:15 - 16:00 Moscone West - Room 3011 CON6573 Data Management and Security in the GDPR Era EUの一般データ保護規制(GDPR)は、2018年5月25日に発効される現在最も重要なデータ保護法です。 GDPRの罰金は最大で企業売上の4%になる可能性があり、経営レベルでの重要な課題となっています。また、データベースとその中に格納されているプライバシー情報は、GDPR対策で非常に重要です。本セッションでは、GDPRがデータを管理する上での影響、準備戦略、および適用可能なデータベース機能をご紹介します。 15:45 - 16:30 Moscone West - Room 3007 CON7075 Keep Structured and Unstructured Data Secure in the Cloud クラウドアプリケーションでもデータセキュリティに対する責任は顧客が負います。本セッションでは、構造化と非構造化データの両方へ、予測的、予防的、発見的な制御を包括的なデータセキュリティを提供するOracle CASB Cloud Serviceをご紹介します。 また、DLP、マルウェア対策、リアルタイム防止のために最新機能もご紹介します。 17:45 - 18:30 Moscone West - Room 3007 CON7083 Granular Access Control for Blockchain Security ブロックチェーンは様々なシーンで利用されています。本セッションでは、Oracle Cloudで提供しているブロックチェーン・サービスへの詳細なアクセス制御ポリシーを実施する方法をご紹介します。また、Oracle Identity Cloud Serviceによるブロックチェーンへのアクセス制御や、Oracle Cloudのサービスやカスタムアプリケーションと統合についてもご紹介します。   ■ 10/4(水) 時間・会場・ID セッション名 セッション概要 11:00 - 11:45 Moscone West - Room 3014 CON6572 Inside the Head of a Database Hacker パッチ未適用、脆弱なアカウント、暗号化されていないデータなど一般的な脆弱性を利用し、ハッカーが情報を盗みだすのは簡単です。ただし、ハッカーの心を知ることで、データベース保護の青写真を戦略的に作成することができます。本セッションは、Oracle Databaseのセキュリティ・アーキテクトが、脆弱性を悪用しデータベース内の機密情報へアクセスするサイバー犯罪者の心理を意識し、阻止する方法を紹介します。

いよいよ来週、Oracle OpenWorld 2017が開催されます。 セキュリティ関連では、お客様の活用事例の最新製品紹介やEU GDPR関連のセッションなど多くが開催されます。 ここでは、データベースセキュリティ、ID管理(IDaaS)、CASB関連のおすすめセッションをご紹介します。 現地に行かれる方は是非、ご参加ください。また、すべてのセキュリティ関連のセッションについては、以下のURLを...

ID管理・認証

[第52回] OS認証

バッチスクリプトにユーザー名/パスワードを書かないためのOracle Databaseの機能として、外部認証機能があります。これはOSやRADIUSなどデータベースの外部に認証を移譲する機能です。この機能を利用することでたとえば以下のようにユーザー名/パスワードを指定せずにデータベースに接続することができるようになります。 [puku@panca ~]$ sqlplus /@orclpdb SQL*Plus: Release 12.2.0.1.0 Production on 水 9月 20 10:31:15 2017 Copyright (c) 1982, 2016, Oracle. All rights reserved. Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production に接続されました。 SQL> (2017/12/18追記) SYSユーザーが「/ as sysdba」とパスワードなしで接続できる機能とは別機能です。こちらの機能に関しては第5回「データベース管理者と認証」を参照してください   この方法を利用することでバッチスクリプトにユーザー名/パスワードを書かなくても、バッチを特定のOSユーザーから実行するとデータベースで改めてユーザー名/パスワードを聞かれることなくにログインして処理を実行することができるようになります。ただし、認証をOSに移譲しているだけであって、OSユーザーの管理がより重要になりますので必ずしもデータベースで認証するよりも安全とは限りませんので注意が必要です。バッチスクリプトはパスワード管理機能を持った運用ツールから実行したほうが安全ですが、Oracle Databaseにはこのような機能もあるということで紹介します。 OSで認証されるユーザーを作成するには、データベースユーザー作成時にパスワードを指定する代わりに外部ユーザーであること(identified externally)を指定して作成します。また、作成するユーザー名はOSユーザー名の先頭にOS_AUTHENT_PREFIX初期化パラメータの値を付けたもので作成する必要があります。OS_AUTHENT_PREFIX初期化パラメータのデフォルト値はops$ですので、たとえばOSユーザー名がpukuの場合、ops$pukuという名前でデータベースユーザーを作成する必要があります。ユーザーを作成するCREATE USER文は以下の通りです。 create user ops$puku identified externally; データベースに接続する権限も併せて必要です。 grant create session to ops$puku; つぎにOS認証を利用するための設定を確認していきます。 OS認証をおこなうためには、セキュリティの担保のために、リスナー経由のOracle Net接続ではなく、BEQプロトコルを利用する必要があります。なお、マルチテナント環境でないデータベースやマルチテナント環境のCDBの場合には、ORACLE_SID環境変数を設定することで接続先データベースを指定せずにBEQプロトコルで接続できますが、マルチテナント環境のPDBを利用する場合には、BEQプロトコルを利用する接続のための接続エントリをtnsnames.oraに記載する必要があります。tnnames.oraのサンプルは以下の通りです。 ORCLPDB = (DESCRIPTION = (ADDRESS = (PROTOCOL = BEQ) (PROGRAM = oracle) (ARGS = '(DESCRIPTION = (ADDRESS = (PROTOCOL = BEQ)))')) (CONNECT_DATA = (SERVICE_NAME = orclpdb.jp.oracle.com))) また、データベースの認証方式として、OSでの認証を許可するために、sqlnet.oraファイルのSQLNET.AUTHENTICATION_SERVICESパラメータにWindowsの場合はnts、それ以外のOSの場合にはbeqを含める必要があります。なお、SQLNET.AUTHENTICATION_SERVICESパラメータのデフォルトの値はallでこれはnts、beqを含むすべての認証方式を利用できる値ですので、特に設定しなくても接続可能になります。 それではOSにpukuユーザーで接続して、データベースに接続してみます。 [puku@panca ~]$ id uid=1001(puku) gid=100(users) 所属グループ=100(users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [puku@panca ~]$ sqlplus /@orclpdb SQL*Plus: Release 12.2.0.1.0 Production on 水 9月 20 13:29:28 2017 Copyright (c) 1982, 2016, Oracle. All rights reserved. 最終正常ログイン時間: 水 9月 20 2017 10:31:15 +09:00 Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production に接続されました。 SQL> show user ユーザーは"OPS$PUKU"です。 SQL> 上記のようにOSで認証されている場合には、データベースで再度認証されることなく接続することができます。 今回はバッチスクリプトにユーザー名/パスワードを記載しないように運用する際に利用できるOS認証の機能を紹介しました。ただし、繰り返しになりますがOSに認証を移譲しているだけで、データベースのパスワードの漏えいは防止できますが、OSアカウントをより厳重に管理する必要があり、システム全体のセキュリティを向上するためのものではありません。バッチの実行はパスワード管理機能を持った管理ツールから実行することをお勧めします。 「もくじ」にもどる

バッチスクリプトにユーザー名/パスワードを書かないためのOracle Databaseの機能として、外部認証機能があります。これはOSやRADIUSなどデータベースの外部に認証を移譲する機能です。この機能を利用することでたとえば以下のようにユーザー名/パスワードを指定せずにデータベースに接続することができるようになります。 [puku@panca ~]$ sqlplus /@orclpdbSQL*P...

【セミナーとブースに出展】 9/15 Japan Identity & Cloud Summit 2017

9/15に開催されるJapan Identity & Cloud Summit 2017 (JICS2017)に 日本オラクルも4年ぶりにセッション講演とブース出展いたします。 オラクルが注力しているCASBとIDaaSのソリューションを紹介させて 頂きますので、ご都合つく方、是非会場にお越しください。 ■ セッション 「ここまで来た、クラウドのID管理の活用。IDaaSとCASB ~事例を含め紹介~ 」 時間:14:55-15:20 セッション番号:[GS-07]  講師:日本オラクル株式会社    クラウド・テクノロジー事業統括 Cloud Platformビジネス推進本部    シニアマネージャー 大澤 清吾 講演概要:クラウド型のID管理(IDaaS)やCASBの利用が、日本でも進んできています。          本セッションでは、事例やデモをまじえながら最新情報をご紹介します。 ■ ブース 【CASB/ID管理】 クラウド型のセキュリティソリューションのご紹介 多様なデバイスやクラウドアプリケーションの利用に伴い、クラウド型のID管理(IDaaS)やCASBの利用が、日本でも進んできています。 本ブースでは、Oracle Cloudの事例やセキュリティ製品の最新情報をデモンストレーションを交えてご紹介します。 Oracle Identity Cloud Service (IDCS) Oracle CASB Cloud Service Oracle Identity Management イベント開催概要は以下になります。 ◇ イベント開催概要 ◇ 開催日時:2017年9月15日(金)9:30~17:45(9:00~受付開始) 会場:ANA インターコンチネンタルホテル東京 参加費:無料 詳細内容/ご参加のお申込み ⇒  こちら

9/15に開催されるJapan Identity & Cloud Summit 2017 (JICS2017)に 日本オラクルも4年ぶりにセッション講演とブース出展いたします。 オラクルが注力しているCASBとIDaaSのソリューションを紹介させて 頂きますので、 ご都合つく方、是非会場にお越しください。 ■ セッション「ここまで来た、クラウドのID管理の活用。IDaaSとCASB...

[第51回] バッチスクリプトでの認証

近年のサイバー攻撃の原因の多くを占めているもののひとつに何らかの方法でOSやデータベースのユーザーの認証情報を盗んで、その認証情報を利用して正規ユーザーになりすましてデータにアクセスするというものがあります。 ユーザーの認証情報を盗む手段もいろいろあります。ユーザー名/パスワードがメモされているものを盗み見られることも多いです。物理的に付箋や手帳書かれていることもありますが、電子データとしてファイルに存在する場合もあります。たとえば、WEBブラウザーにログイン情報を保存している方も多いと思います。パソコンがロックされていない状態で放置されている場合、この保存された認証情報を見られてしまう可能性もあります。 外部からのサイバー攻撃の場合だと、バッチなどのスクリプトの中に記載された認証情報が盗み見られるケースを聞きます。バッチスクリプトの中にデータベースのユーザー名/パスワードをそのまま記載しているシステムは思いのほか多いです。データベースサーバー上にあるスクリプトだけでなく、アプリケーションサーバーや運用管理サーバーなどほかのサーバーや運用端末など、さまざまな場所でデータベースの認証情報がファイルに記載されていることがあります。 ファイルに認証情報が記載されていると、漏えいのリスクが高まるだけでなく、パスワード変更の影響範囲が分からなくなり結果としてパスワードが万が一漏れてしまった場合でもパスワード変更ができなくなってしまうこともあります。 ユーザー名/パスワードを指定せずにデータベースに接続する方法として、SYSDBAのOS認証があります。 [oracle@panca ~]$ sqlplus / as sysdba SQL*Plus: Release 12.2.0.1.0 Production on 木 8月 24 10:47:06 2017 Copyright (c) 1982, 2016, Oracle. All rights reserved. Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production に接続されました。 SQL> show user ユーザーは"SYS"です。 SQL> ユーザー名/パスワードを指定しなくても、OSのdbaグループのユーザーであればデータベースに管理者特権で接続できる機能です。 スクリプトにユーザー名/パスワードを記載しないほうが良いなら、この機能を利用すればよいと思う方もいらっしゃるかもしれませんが、この方法も適切とは言えません。 管理者特権で接続しますので、アクセス制御が効かずすべてのデータにアクセスできてしまうため、想定外のデータ操作をされてしまう可能性もあります。セキュリティの基本である最小権限の原則を守り、職務分掌を実現することができません。 また、管理者特権は日常的に利用するべきではないため、不正アクセス検知のために管理者特権での操作を監査していた場合には、不正アクセスのログが業務としての利用ログに埋もれてしまいまい、不正アクセスに気づきづらくなります。 そもそも12c以降のマルチテナントアーキテクチャを利用している場合には、SYSDBAのOS認証機能を利用してPDBに接続することはできません。 バッチなどのスクリプトは、パスワード管理機能を持った運用管理製品を利用して実行するようにしてください。 「もくじ」にもどる

近年のサイバー攻撃の原因の多くを占めているもののひとつに何らかの方法でOSやデータベースのユーザーの認証情報を盗んで、その認証情報を利用して正規ユーザーになりすましてデータにアクセスするというものがあります。 ユーザーの認証情報...

[第50回] アクセス制御を回避する権限

Oracle DatabaseにはSELECTオブジェクト権限やSELECT ANY TABLEシステム権限で表に対するアクセス権限を持っていても、列や行ごとのアクセス制御をおこなう仮想プライベートデータベース(VPD:Virtual Private Database)や、列データをリアルタイムにマスクするData Redactionといった機能があります。これらの機能を活用することで、アプリケーションに影響のないより強力で細かなアクセス制御を実現できます。 しかし、これらのアクセス制御設定を回避するためのシステム権限というものも用意されています。 具体的には仮想プライベートデータベースのアクセス制御を回避するのがEXEMPT ACCESS POLICYシステム権限、Data Redactionのマスキングを回避するのがEXEMPT REDACTION POLICYシステム権限となります。システム権限の一覧はこちらをご参照ください。 デフォルトの状態では、EXEMPT REDACTION POLICYシステム権限がEXP_FULL_DATABASEロール(とこのロールが含まれるDATAPUMP_EXP_FULL_DATABASEロール、さらにこのロールが含まれるDBAロール)に割り当てられています。 SYSユーザーは仮想プライベートデータベースのアクセス制御もData Redactionのマスキングも回避できますが、SYSTEMユーザーであっても仮想プライベートデータベースのアクセス制御は回避できません。しかし、SYSTEMユーザーはDBAロールを持っており、その中にEXEMPT REDACTION POLICYシステム権限が含まれるためData Redactionのマスキングは回避できるということになります。 アプリケーションのユーザーがEXP_FULL_DATABASEロールやDBAロールを持っている場合、Data Redactionは回避されてしまいますので注意が必要です。 なお、これらの権限が誰に割り当てられているかは、DBA_SYS_PRIVSビューから確認できます。 SQL> select grantee from dba_sys_privs 2 where privilege = 'EXEMPT ACCESS POLICY'; no rows selected SQL> select grantee from dba_sys_privs 2 where privilege = 'EXEMPT REDACTION POLICY'; GRANTEE -------------------------------------------------------------------------------- EXP_FULL_DATABASE また、DBSATレポートの「Access Control Exemption Privileges」セクションからも確認できます。 せっかくアクセス制御を設定しててもこれらの権限によりアクセス制御が聞かないことがありますのでご注意ください。 「もくじ」にもどる

Oracle DatabaseにはSELECTオブジェクト権限やSELECT ANY TABLEシステム権限で表に対するアクセス権限を持っていても、列や行ごとのアクセス制御をおこなう仮想プライベートデータベース(VPD:Virtual Private Database)や、列データをリアルタイム...

データベースセキュリティ

[第49回] ネットワーク分離していれば安全?

「うちはネットワークを分離しているから安全」という言葉をよく聞きます。 さて、ネットワークを分離していれば安全なのでしょうか? まず、完全に外部とのネットワーク分離をしている場合、外部とのデータのやり取りはどのようにおこなっているのでしょうか? そのシステムに対して、データをどのように投入して、プログラム更新やウイルス対策ソフトのアップデートなどがあった場合にはどのように適用して、外部システムにどのようにデータを配信・連携しているのか、など完全にネットワーク分離をしている場合でも、何らかの方法で外部とのファイルの受け渡しがある場合があります。ネットワーク分離をしている場合、どのような中継サービスがありそれらがすべてきちんと管理されているかどうか確認する必要があります。 外部とのファイルのやり取りができない場合、利便性のために新しいUSBデバイスや無線LANルーターなどを利用した外部ネットワーク接続など外部とファイルをやり取りできる想定外の「仕組み」を作ってしまっていたりすることもありあます。情報を漏えいさせてやろうという悪意がなく純粋に自分や同僚の利便性のための善意でう回路を作ってしまっているかもしれません。 また、業務上必要な場合でも一度外部にデータが出てしまうとデータの安全性を保障することはできません。外部に保存する場合には暗号化すること、使い終わったらすぐに消すこととルールで決まっていても、利便性のために暗号化しなかったり、また使うかもしれないからといつまでも残ってしまうこともあるかもしれません。分離されたネットワーク上のマシンには便利なソフトが入っていないため、持ち出しが必須ではないファイルまで持ち出してしまうかもしれません。 ネットワークとしては完全に分離できていても、中に入れる人を十分に管理できていない場合もあります。業務を担当する社員のほかにも、無関係の社員や委託会社、協力会社の下請け、ベンダの作業員など想定外の人が分離されたネットワークの中で作業しているかもしれません。 一方、外部や社内向けサービスをおこなっているサーバー群への管理セグメントが分離されているというケースもあります。 この場合でも上記のリスクはのこり、さらに外部や社内向けサービスのStrutsやSQLインジェクションなどの脆弱性をついてサイバー攻撃を受けるリスクがあります。 「クラウドはセキュリティが心配だから」という声もよく聞きました。 しかし、パブリッククラウドも社内とは別のネットワークセグメントにある仮想サーバーにVPNなど決められた方法でしか接続できないというネットワーク分離された環境ということもできます。データセンターが物理的なラックを貸しているのか、仮想化環境を貸しているのかの違いしかありません。 ネットワーク分離は非常に強力なセキュリティのソリューションです。しかし、だからこそネットワーク分離ばかりに頼りがちになり、その他の対策がおろそかになってしまっている状況もよく見かけます。例えばログはネットワーク分離の境界、たとえば踏台サーバーの画面ログとファイルのアップロード/ダウンロードでしかとっていないなどです。これでは画面に出力されない処理は全くログに残りません。一度何らかの方法で中に入られてしまうと何がおこなわれたかを確認するすべがありません。ネットワーク分離などで想定できる脅威からの対策は十分にできていると考えているかもしれません。 しかし、ネットワーク分離された環境から情報漏えい事件が発生しているのも事実です。想定外の手段で意図せず、もしくは故意にデータが持ち出され、漏えいしてしまっています。 たとえネットワーク分離をおこなっている場合でも、分離されたネットワーク内でのセキュリティ対策も重要です。ネットワークで外からの攻撃を防ぐ対策をおこなったあとには、データベースで情報を中から守る多層防御のセキュリティ対策をぜひ実施してください。 「もくじ」にもどる

「うちはネットワークを分離しているから安全」という言葉をよく聞きます。 さて、ネットワークを分離していれば安全なのでしょうか? まず、完全に外部とのネットワーク分離をしている場合、外部とのデータのやり取りはどのようにおこなっているのでしょうか? そのシステムに対して、データをどのように投入して、プログラム更新やウイルス対策ソフトのアップデートなどがあった場合にはどのように適用して、外部システム...

データベースセキュリティ

[第48回] データベースセキュリティのガイドライン

Oracle Database 12cR2の情報がまとめられた特設ページ(リンク集)が新しくでいたようです。このブログも紹介されていますが、データベースセキュリティ以外の各種情報が載っているので、アクセスしてみてください。   データベースを安全に構築・管理・運用するうえで気を付けるべきポイントはこのブログの第1回「はじめに ~ データベースセキュリティの基本的な考え方」で紹介しました。ただ、このポイントは概念的すぎます。具体的な実装手段はこのブログで順次紹介していっていますが、残念ながらまだ「ID管理・認証」と「アクセス制御」のことにしか触れられていません。「暗号化」や「監査・監視」など考えなければならないことはたくさんあります。このブログでも順次詳しく紹介していきますが、とりあえず直近で作成するシステムのために全体感を知りたい方も多いでしょう。 ということで、データベースを安全に構築・管理・運用するうえで気を付けるべきポイントを本連載の1回目より具体的に記載されているものを紹介します。 1. データベースセキュリティコンソーシアムのデータベースセキュリティガイドライン データベースセキュリティの指針、考え方が日本語でまとめられている数少ないガイドラインのひとつです。第2.0版が2009年に出ています。少し古く感じるかも知れませんが、データベースセキュリティの考え方や実施しなくてはならないセキュリティ対策というのはずっと変わっていません。ぜひご一読ください。 また、データベースセキュリティコンソーシアムからは、統合ログ管理サービスガイドライン、データベース暗号化ガイドライン、DB内部不正対策ガイドラインなども様々なガイドラインや、管理者の10人に1人は「情報を売却するかも知れない」という衝撃の結果が載っている「DBA 1,000人に聞きました」アンケート調査報告書なども公開されています。   2. 米国国防情報システム局(DISA:Defense Information Systems Agency)のセキュリティ技術実装ガイド(STIG:Security Technical Implementation Guide) 英語になりますが、より具体的に記載されているのがDISAのSTIGです。 Oracle Databaseに限らず各データベースの各バージョンごと何をすべきかが公開されています。 「インスタンス名にオラクルのバージョン番号を入れないこと(Oracle instance names must not contain Oracle version numbers.)」というような運用ルールから、「_TRACE_FILES_PUBLICパラメータが設定されている場合にはFALSEにすること(The Oracle _TRACE_FILES_PUBLIC parameter if present must be set to FALSE.)」というような細かい具体的な設定まで多種多様な項目が掲載されています。STIGの良いところは、設定が必要な理由(Vulnerability Discussion)、確認方法(Check Content)、改善方法(Fix Text)がセットで記載されていることです。このブログの第2回で紹介したDBSATの詳細なマニュアル版といっても過言ではありません。 細かすぎるところはありますが、書かれている内容は具体的で非常に参考になります。 Oracle Database 12cR2からは、このSTIGに合致するパスワード検証ファンクションとユーザープロファイルが事前定義され、いくつかの初期化パラメータのデフォルト値がSTIG対応の値に変更されています。「セキュリティガイド」マニュアルの「STIGコンプライアンス機能」を参考にしてください。   3. 「セキュリティガイド」マニュアルの「Appendix A Oracle Databaseの安全性の維持」 Oracle Databaseのマニュアルにも、データベースの安全性を維持するためのガイドラインを公開しています。   これらのガイドラインを参考にして、重要なデータを守るためにデータベースのセキュリティもシステム設計時に考慮してください。 「もくじ」にもどる

Oracle Database 12cR2の情報がまとめられた特設ページ(リンク集)が新しくでいたようです。このブログも紹介されていますが、データベースセキュリティ以外の各種情報が載っているので、アクセスしてみてください。   データベースを安全に構築・管理・運用するうえで気を付けるべきポイントはこのブログの第1回「はじめに ~ データベースセキュリティの基本的な考え方」で紹介しました。ただ...

ID管理・認証

[第47回] 利用していないユーザー、利用しなくなったユーザー

お客様のデータベースのセキュリティアセスメントを実施していると、結構な割合のシステムでアプリケーションのユーザーしかないというケースに遭遇します。 第3回「アカウント管理の重要性」でも説明しましたが、「共有ユーザー利用などの匿名性を排除する」ためには、データベースを管理者やクライアントから直接アクセスする利用者の個人アカウントを作成することが重要です。 しかし、管理者や利用者は部署移動や退職によって変わっていきます。 また、本番データベースにデータ移行や一時的にアカウントを作成することもあるでしょう。 既に部署移動や退職した人、一時利用のために作成したアカウントで既に利用していないものが残っているケースをセキュリティアセスメントで見つけることもたびたびあります。データベースユーザーの一覧の見方も第3回「アカウント管理の重要性」で紹介していますが、このリストを見ながら「このユーザーは何のためのユーザーですか?」とヒアリングすると「○○チェックのために依頼されて作成したユーザーです」と説明を受けるのですが、他部門からの依頼のため現在の利用状況を把握できておらず、チェックのために全データにアクセスできる強力な権限が付与されていたこともあります。 12cR1からDBA_USERSビューに追加されたユーザーの最終ログイン時間を格納するLAST_LOGIN列の値を確認することにより、ユーザーが利用されているかどうかを確認することができます。 また、それ以前のバージョンでもパスワードの有効期限が設定されていれば長期間利用されていないユーザーはEXPIREDされ、その時間がEXPIRY_DATE列に記録されます。パスワード有効期限機能を有効にしている場合には、12cより前のバージョンでも長期間利用されていないユーザーが確認できます。 パスワードの有効期限が切れて、EXPIREDのステータスのユーザーでもユーザーを利用し続けることができることは第41回「12cR2でのアカウント管理の強化」でも紹介しました。   NISC(内閣サイバーセキュリティセンター)では、2016年10月7日に近年の標的型攻撃等の高度サイバー攻撃の増加にともない、府省庁や独立行政法人等に向けて「高度サイバー攻撃対処のためのリスク評価等のガイドライン」を公開しました。 このガイドラインの「付随書」の中の「付属書2 標的型攻撃への対処のための対策セット」で高度サイバー攻撃の「攻撃手法」について、「管理者権限アカウント等を窃取しながら、侵入範囲を拡大する」と説明しています。 不要なアカウントが残っている場合、こういった攻撃に使われることもあります。 利用していないユーザーは必ず削除するか、LOCKするようにしてください。 みなさまのシステムでもこの機会に一度ユーザーの棚卸をしてみてはいかがでしょうか? 「もくじ」にもどる

お客様のデータベースのセキュリティアセスメントを実施していると、結構な割合のシステムでアプリケーションのユーザーしかないというケースに遭遇します。 第3回「アカウント管理の重要性」でも説明しましたが、「共有ユーザー利用などの匿名性を排除する」ためには、データベースを管理者やクライアントから直接アクセスする利用者の個人アカウントを作成することが重要です。 しかし、管理者や利用者は部署移動や退職によっ...

データベースセキュリティ

[第46回] ディレクトリオブジェクト

Oracle Databaseで外部ファイル操作をおこなう際に利用するのがディレクトリオブジェクトです。 ディレクトリオブジェクトを利用することで、外部ファイルに対するアクセス権限をユーザーごとに細かく設定することができます。 昔はUTL_FILE_DIR初期化パラメータも外部ファイル操作をおこなう際のディレクトリ指定に使用してきましたが、現在は非推奨となっています。第40回「セキュリティ関連の初期化パラメータ (6)」のUTL_FILE_DIRの記載も併せて参照してください。 セキュリティの考え方で重要なのが「最小権限の原則」ですが、ディレクトリオブジェクトへのアクセス権限でも当てはまります。 データベースの中できちんとアクセス制御をおこなっていても、ディレクトリオブジェクトへのアクセス権限が適切でない場合、データベースのアクセス制御が及ばないOSファイルにデータベースのデータを書き出すことができるようになってしまいます。 ディレクトリオブジェクトを利用するケースで一番多く利用されるであろうものが、エクスポート/インポート処理です。 この処理では表やスキーマ、データベース全体のデータを一度にファイルに書き出すことができます。書き出されたダンプファイルにはデフォルトではセキュリティはかかっていませんので、このダンプファイルは誰でも別のデータベースにインポートすることができます。ダンプファイルからの情報漏えいには十分注意してください。Oracle Advanced Securityオプションを利用することでダンプファイルを暗号化することもできますので、必要であれば考慮してください。 また、エクスポート/インポート処理をおこなうユーザーにEXP_FULL_DATABASE、IMP_FULL_DATABASEロールを付与するケースもあると思いますが、このロールには非常に強力な権限が付与されています。エクスポート/インポート処理をおこなう際には専用のユーザーを作成しパスワードを厳重に保護するなど厳密なアカウント管理をおこなってください。第18回「エクスポート/インポートで利用する権限の注意点」も併せて参照してください。 しているシステムもあるかもしれません。しかし、エクスポート/インポートをバックアップとして利用する場合にはデータロスが発生するなどの注意点があります。詳細はDB ONLINEの記事「目指せ黒帯!Oracle Database バックアップ&リカバリ道場」の「論理バックアップはDBバックアップとして適切か?」を参照してください。 ディレクトリオブジェクトはUTL_FILEパッケージで入出力可能なファイルのディレクトリを指定するためにも利用します。 下記のサンプルスクリプトを見てください。 declare vHandle utl_file.file_type; begin vHandle := utl_file.fopen('BATCHDIR','dailybatch.sh','w',32767); utl_file.put_line(vHandle,'sqlplus / as sysdba <<EOF');   utl_file.put_line(vHandle,'shutdown abort');   utl_file.put_line(vHandle,'EOF');   utl_file.fflush(vHandle);   utl_file.fclose(vHandle); exception when others then   utl_file.fclose_all;   raise; end; / このスクリプトはdailybatch.shというファイルをデータベースを停止するスクリプトに書き換えています。 もしこの書き換えられたバッチが実行されてしまった場合、データベースが停止してしまいます。 バッチで利用するデータをUTL_FILEパッケージを利用して作成することもあると思いますが、実行可能なバッチ本体をディレクトリオブジェクトで指定したディレクトリに配置することは非常に危険です。 なお、UTL_FILEパッケージでファイル操作をおこなう際には、ローカル接続の場合はサーバープロセスを起動したユーザー権限で、リスナー経由の接続の場合にはリスナーを起動したユーザー権限でファイル操作をおこないます。新規ファイルを作成する場合には該当ユーザーのumaskで設定したパーミッションでファイルが作成されますので、不用意に実行可能なファイルが作成されないように注意が必要です。 UTL_FILEパッケージに関しては、このパッケージはデフォルトでPUBLICロールに対してEXECUTE権限が付与されています。つまり、ディレクトリオブジェクトへのアクセス権限を付与されたデータベースユーザーは誰でもUTL_FILEパッケージを利用してファイル入出力を実行できることになります。ディレクトリオブジェクトへの不必要な読み取り権限があるだけで、ほかの人がデータベースから書き出した本来その人はアクセスすることができないデータにアクセスされてしまったり、書き込み権限があれば改ざん・破壊されてしまう可能性もあります。 UTL_FILEパッケージのEXECUTE権限に関しては、デフォルトでは下位互換のために付与されていますが、Database Vaultを有効にするとセキュリティ強化のため、PUBLICロールからUTL_FILEパッケージのEXECUTE権限が取り消されます。 Database Vaultを利用していない場合でも、既存のアプリケーションに影響がない場合には権限を取り消すこともセキュリティ強化のために有効です。 データ連携などのために外部ファイルにデータを書き出す必要がある場合も多いと思いますが、なるべく外部ファイルに書き出さないようにするとともに、外部ファイルに書き出したデータもデータベース内に格納されているデータと同様のセキュリティポリシーで保護されるように注意してください。 「もくじ」にもどる

Oracle Databaseで外部ファイル操作をおこなう際に利用するのがディレクトリオブジェクトです。 ディレクトリオブジェクトを利用することで、外部ファイルに対するアクセス権限をユーザーごとに細かく設定することができます。 昔はUTL_FILE_DIR初期化パラメータも外部ファイル操作をおこなう際のディレクトリ指定に使用してきましたが、現在は非推奨となっています。第40回「セキュリティ関連の初期...

データベースセキュリティ

[第45回] Oracle Databaseのセキュリティパッチ

オラクルではセキュリティ修正を含む累積パッチを四半期ごとにCritical Patch Updateとして定期的に提供しています。脆弱性をついた攻撃が発生したときには、これとは別に緊急の個別パッチがでることもありますが、基本的には四半期ごとの累積パッチを適用することで既知の脆弱性への対策ができている最新の状態を保つことができます。 最近のコンプライアンス要件でも、ソフトウェアを最新の状態に保つことが求められています。   「個人情報の保護に関する法律についてのガイドライン(通則編)」では、講じなければならない措置として「(3)外部からの不正アクセス等の防止」があり、実現のための手法として「機器やソフトウェア等に標準装備されている自動更新機能等の活用により、ソフトウェア等を最新状態とする」とあります。 「PCIDSS」では、「要件:6.2」で「すべてのシステムコンポーネントとソフトウェアに、ベンダ提供のセキュリティパッチがインストールされ、既知の脆弱性から保護されている。重要なセキュリティパッチは、リリース後 1 カ月以内にインストールする」とあります。 また、「政府統一基準」でも、「6.2.1 ソフトウェアに関する脆弱性対策」の遵守事項として「(1) ソフトウェアに関する脆弱性対策の実施」、「(a) 情報システムセキュリティ責任者は、サーバ装置、端末及び通信回線装置の設置又は運用開始時に、当該機器上で利用するソフトウェアに関連する公開された脆弱性についての対策を実施すること」とあります。この内容は「7.2.4 データベース」の目的・趣旨に「なお、本項の遵守事項のほか、6.1 節「情報システムのセキュリティ機能」において定める主体認証・アクセス制御・権限管理・ログ管理・暗号・電子署名等の機能面での対策、6.2.1項「ソフトウェアに関する脆弱性対策」、6.2.2 項「不正プログラム対策」、7.3.2 項「IPv6 通信回線」において定める遵守事項のうち、データベースに関係するものについても併せて遵守する必要がある」とデータベースでも遵守するように明記されています。 オラクルでは新しくパッチを作成するバージョンをサポートポリシーとして定義しています。具体的には「Critical Patch Updatesの提供」はPremier SupportおよびExtended Support期間中に限られます。Sustaining Support期間中のバージョンに関してはCritical Patch Updatesは提供されません。 Oracle Databaseの場合、2017年7月の時点でのサポート期間、11.2のExtended Supportは2020年12月まで、12.1のExtended Supportは2021年7月までとなってます。この期間以降はパッチが作成されなくなりますので注意が必要です。 パッチが提供されないデータベースバージョンを利用することは各種コンプライアンス要件への違反と判断されるケースもありますので、定期的なアップグレード計画を立てることが重要です。 さて、この四半期ごとに提供されるパッチをすぐに当て続けないとこれらのコンプライアンス要件に準拠できないかというと、実はそんなことはありません。PCIDSSでも「重要なセキュリティパッチは、リリース後 1 カ月以内にインストールする。」と明文化されていますが、「重要な」というように限定がありすべてのセキュリティパッチを即座に適用し続けることは必須の要件とはなっていません。もちろん脆弱性をつく攻撃が起きている場合にはその対策のためのパッチは「重要なセキュリティパッチ」であるため即座に適用しなければなりませんが、すべてのセキュリティパッチを即座に適用する必要があるわけではありません。逆に「重要なセキュリティパッチ」でないからと言って、ずっと当てなくてよいものでもありません。その時点でその脆弱性をついた攻撃がなくても将来的にその脆弱性をついた攻撃が起きるかもしれません。攻撃を受けたときに数年前に修正されていた脆弱性をほったらかしておいたので被害を受けました、ということになっては元も子もありません。 重要なのはパッチの適用計画を準備しておくことです。即座に適用すべき「重要なセキュリティパッチ」の判断基準をはっきりとさせ、そうでないセキュリティパッチの適用頻度を決定し、パッチ適用時の既存アプリへの影響調査を含めた手順を確立しておくことです。 「重要なセキュリティパッチ」かどうかの判断としては、たとえばJPCERTの注意喚起が利用できます。ただし、ここではその脆弱性をついた攻撃が発生していることを紹介しているため、注意喚起の時点で情報漏えいが発生してしまっている可能性もあります。ベンダーやセキュリティ専門会社の注意喚起も併せて確認することをお勧めします。オラクルからも英文ではありますが、セキュリティパッチやセキュリティアラート情報をメール配信するサービスをおこなっています。 また、パッチの内容の詳細までは公開されていませんが、データベースサーバーのどのコンポーネントに対するパッチかは公開されています。たとえば、2017年4月の累積パッチはデータベースのSQL*PlusとJVMに関するパッチが含まれていることが分かります。パッチはシステムが利用しているコンポーネントに対するものかどうか、Base Scoreの値の大きさなども「重要なセキュリティパッチ」かどうかの判断基準にできます。 次に「重要なセキュリティパッチ」ではないパッチの適用周期ですが、これはシステムの重要度やメンテナンス停止が可能な頻度によります。Windowsなどのセキュリティパッチを適用していないことはないと思います。これはWindowsは頻繁にファイル入出力などのアクセスをおこなうためだと思います。同様にサーバーもサービス提供のために、さまざまな端末と通信できる状態にあります。サーバーに対しても定期的にパッチを適用するようにしてください。 (2017/09/26追記) パッチが公開されると、公開されたパッチをリバースエンジニアリングして、脆弱性を突き止め、パッチ未適用環境への攻撃ツールが作成される危険性もあります。この観点からも定期的にパッチを適用していくことは重要です。 さて、パッチを適用する際に重要なのは影響調査です。パッチを適用していない最大の理由はなんらかの悪影響が出てしまうと困るから、影響が分からないからだと思います。影響調査をおこなわず緊急のパッチ適用をしてしまったため、性能トラブルを起こしてしまったなどのケースもあるかもしれません。ただし、これはデータベースのセキュリティパッチ適用時のみに起こることではありません。ハードウェア更新、ソフトウェアのアップグレード、チューニングのためのデータベースパラメータの変更など事前に影響調査をおこなうべき作業はどのシステムにもあります。パッチ適用のためだけでなく、ほかの作業実施時のためにも影響調査の手順は確立しておくことをお勧めします。 パッチ適用やアップグレード時の影響調査を効率的におこなうためにOracle DatabaseではReal Application Testingというテストツールを用意しています。このツールを利用することで、既存の本番データベースのワークロード(指定した期間内で実際に発行されたSQL文と発行されたタイミング)を記録し、別の環境でリプレイ(再現)することができます。このツールを利用することで、パッチ適用前後の環境下での性能や実行計画などの違いを確認することができます。以下にテストツールの概要や使い方、デモなどがありますのでこちらもご参照ください。 DB Upgradeの極意: アップグレードのリスクを軽減!データベーステストのベストプラクティス ~オラクルコンサルタントが語る~ シンジ&アヤノの実践データベース性能テストの極意:Oracle Real Application Testingを使ってみよう  「もくじ」にもどる

オラクルではセキュリティ修正を含む累積パッチを四半期ごとにCritical Patch Updateとして定期的に提供しています。脆弱性をついた攻撃が発生したときには、これとは別に緊急の個別パッチがでることもありますが、基本的には四半期ごとの累積パッチを適用することで既知の脆弱性への対策ができている最新の状態を保つことができます。 最近のコンプライアンス要件でも、ソフトウェアを最新の状態に保つことが求...

セキュリティ全般

オラクル・データベースセキュリティお客様活用事例

顧客事例/ニュースリリースとして発表させていただいたお客様及びメディア掲載いただいたお客様の事例をご紹介します(五十音順)。 ■ データベースセキュリティ SBIトレードウィンテック (Advanced Security, Database Vault, Audit Vault and Database Firewall) 事例 (PDF)  エディオン  (Advanced Security) 事例 (PDF) 性能向上は当然、コストも大幅削減:エディオンが「約1200店舗の業務をリアルタイムに支える統合データベース基盤」にOracle Exadataを選んだ理由 KDDIエボルバ (ファイングレイン監査, Data Masking and Subsetting) 札幌市 (Data Masking and Subsetting) セブン&アイ・ホールディングス (Advanced Security, Database Vault, Audit Vault and Database Firewall) 日本精工 事例 (PDF) 野村総合研究所 (Advanced Security, Database Vault) 白十字会 佐世保中央病院 (ファイングレイン監査, Advanced  Security) 事例 (PDF) わずか1分で移行! 佐世保中央病院がOracle GoldenGateで電子カルテの基幹DBをスピード移行。データ暗号化、先進監査機構でセキュリティも強化 バンダイ (Advanced Security, Database Vault, Audit Vault and Database Firewall, Data Masking and Subsetting) 事例 (PDF)  高速かつ高セキュリティなDB基盤が“日本発キャラクター”のグローバル展開を加速: 繁忙期のリクエスト処理能力が10倍超に! 「プレミアムバンダイ」は性能不足の問題をOracle Exadataで解決  プロトコーポレーション (Advanced Security) ベリトランス (Advanced Security) 急がれるPCI DSS準拠、ベリトランスはどう対応したのか。確実かつ効率的なソリューションは? ー クレジットカード含む全データの暗号化をどう実現したか? Oracle Magazine : Oracle Exadataの採用で、クレジットカード業界をリードする 次世代決済プラットフォームへ刷新 マツダ 三菱アルミニウム (Advanced Security) 基幹DBのBCP対策強化、管理性と性能の大幅向上を実現:三菱アルミニウムがマルチテナント機能で販売/生産管理データベースを一挙集約し、事業継続性も強化。その選択の理由とは? ヤフー (Database Vault) Oracle Database Vaultって本当に必要ですか? データを守るためよりもむしろメンバーを守るためにこそいるのです 楽天証券 (Advanced Security, Database Vault, Audit Vault and Database Firewall)     事例 DBアクセス制御、暗号化、監査で高セキュアな個人情報管理を実現:楽天証券は多層防御でマイナンバーを安全管理 オラクルのデータベースセキュリティ製品はどう使われたのか?  ラクロス (Advanced Security)  良品計画 (Audit Vault and Database Firewall) 事例 (PDF)

顧客事例/ニュースリリースとして発表させていただいたお客様及びメディア掲載いただいたお客様の事例をご紹介します(五十音順)。 ■ データベースセキュリティ SBIトレードウィンテック (Advanced Security, Database Vault, Audit Vault and Database Firewall) 事例 (PDF)  エディオン  (Advanced Security) 事例...

ID管理・認証

Oracle IDM製品が、ガートナー マジック・クアドラントでアクセス管理分野の「リーダー」に位置付けられました

Oracle Identity Management 製品が「Gartner Magic Quadrant for Access Management」でリーダーの位置付けになりました。 USでは既にプレスリリース済みですが、日本についても本件についても以下の通りをさせて頂きました。 オラクル、2017 ガートナー マジック・クアドラントでアクセス管理分野のリーダーに位置付け 今回のリーダーとしての位置付けは、今年提供開始した「Oracle Identity Cloud Service」による特徴的なサービス強化を高く評価すると考えられます。  また、OracleのIDM製品は「Magic Quadrant for Identity Governance and Administration」でも4年連続でリーダーに位置付けられております。 Oracle Identity Cloud Service やCASB Cloud ServiceなどOracle Identity Management 製品群の紹介資料は、以下にアップしておりますので、ご活用ください。 CASB Cloud Service / Identity Cloud Service ご紹介    ※ 本図表は、ガートナー・リサーチの発行物の一部であり、評価するには発行物全体をご覧いただく必要があります。ガートナーの発行物は、リクエストにより日本オラクルからご提供することが可能です。 ガートナーは、ガートナー・リサーチの発行物に掲載された特定のベンダー、製品またはサービスを推奨するものではありません。また、最高のレーティング又はその他の評価を得たベンダーのみを選択するよう助言するものではありません。ガートナー・リサーチの発行物は、ガートナー・リサーチの見解を表したものであり、事実を表現したものではありません。ガートナーは、明示または黙示を問わず、本リサーチの商品性や特定目的への適合性を含め、一切の保証を行うものではありません。 Source: Gartner  Magic Quadrant for Identity Governance and Administration |Published: 22 February 2017 ID: G00302686 Analyst(s): Felix Gaehtgens, Perry Carpenter, Brian Iverson, Kevin Kampman Source: Gartner Magic Quadrant for Access Management, Worldwide|Published: 7 June 2017 ID: G00315479 Analyst(s): Gregg Kreizman, Anmol Singh

Oracle Identity Management 製品が「Gartner Magic Quadrant for Access Management」でリーダーの位置付けになりました。 USでは既にプレスリリース済みですが、日本についても本件についても以下の通りをさせて頂きました。 オラクル、2017 ガートナー マジック・クアドラントでアクセス管理分野のリーダーに位置付け 今回のリーダーとしての位置...

今さら? 今こそ! データベースセキュリティ(2):なぜ、データベースセキュリティが必要か──企業の対策率「たった20%」の現状

@ITで連載している「今さら? 今こそ! データベースセキュリティ」の第2回「なぜ、データベースセキュリティが必要か──企業の対策率「たった20%」の現状」が公開されました。 ぜひ、アクセスしてみてください。   今さら? 今こそ! データベースセキュリティ(2): なぜ、データベースセキュリティが必要か──企業の対策率「たった20%」の現状 本連載では、データベースセキュリティの「考え方」と「必要な対策」をおさらいし、Oracle Databaseを軸にした「具体的な実装方法」や「Tips」を紹介していきます。今回は、あらためて「なぜ、データベースセキュリティが必要なのか」を説明します。

@ITで連載している「今さら? 今こそ! データベースセキュリティ」の第2回「なぜ、データベースセキュリティが必要か──企業の対策率「たった20%」の現状」が公開されました。 ぜひ、アクセスしてみてください。   今さら? 今こそ! データベースセキュリティ(2):なぜ、データベースセキュリティが必要か──企業の対策率「たった20%」の現状 本連載では、データベースセキュリティの「考え方」と「必要な対策」を...

データベースセキュリティ

[第44回] SQLインジェクション、その3。動的SQL文の利用とサニタイズ(エスケープ)

ここまではアプリケーションが発行するSQL文の構文がほぼ決まっているケースを紹介しました。しかし、アプリケーションによっては、検索条件列を自由に組み合わせられるなど、動的にSQL文が生成されるケースもあります。動的にSQL文を生成するケースでは文字列を連結してSQL文を生成することが多いです。このような場合でも、SQL構文は文字列の連結で生成しても、ユーザーの入力値にはバインド変数を利用することも可能です。下のサンプルアプリケーションは名前、住所、電話番号で部分一致検索が可能なアプリケーションです。 ここで名前に「田」が住所に「市」という文字が含まれるという条件で検索してみます。SQL文が動的に生成され、NAME列とADDRESS列への検索条件が含まれていますが、バインドが利用されているのが分かります。 画面に条件が入力された場合に、動的にSQL文を生成し、バインド変数を利用した条件句を追加するコードは、例えば以下のような形で実現できます。 String sqltext = "select name, address, phone from dbsecdemo.addrbook where "; if (!inName.isEmpty()) sqltext = sqltext + "name like ? and "; if (!inAddr.isEmpty()) sqltext = sqltext + "address like ? and "; if (!inPhon.isEmpty()) sqltext = sqltext + "phone like ? and "; sqltext = sqltext.substring(0, sqltext.length()-7); if (!(inName.isEmpty() & inAddr.isEmpty() & inPhon.isEmpty())) sqltext = sqltext + " escape '\\'"; out.println(sqltext + " "); PreparedStatement pstmt = conn.prepareStatement(sqltext); int i = 1; if (!inName.isEmpty()) { pstmt.setString(i, "%" + inName.replaceAll("\\\\","\\\\\\\\").replaceAll("%","\\\\%").replaceAll("_","\\\\_") + "%"); i = i + 1; } if (!inAddr.isEmpty()) { pstmt.setString(i, "%" + inAddr.replaceAll("\\\\","\\\\\\\\").replaceAll("%","\\\\%").replaceAll("_","\\\\_") + "%"); i = i + 1; } if (!inPhon.isEmpty()) pstmt.setString(i, "%" + inPhon.replaceAll("\\\\","\\\\\\\\").replaceAll("%","\\\\%").replaceAll("_","\\\\_") + "%"); ResultSet rset = pstmt.executeQuery(); 動的SQLの利用とバインド変数の利用は両立可能ですので、動的SQLをどうしても利用しなくてはならない場合でも、文字列結合による検索条件の値の設定はおこなわないようにすることを推奨します。   さて、文字列結合を利用している場合でもSQLインジェクションの対策としてSQLインジェクションに利用される文字をエスケープするなどサニタイズする方法があります。 Oracle Databaseでは、DBMS_ASSERTパッケージを用意しており、例えばENQUOTE_LITERALファンクションでは、引数を半角シングルクォート「'」で囲い、同時に途中にシングルクォートがないことを確認して文字列が途中で切れていないことを保証します。このパッケージはSQLインジェクション対策に利用することができますが、あくまでPL/SQLでプログラムを書いているときのみです。JAVAでプログラムを書いている場合にはこのパッケージを利用してもSQLインジェクションを確実に防げないケースもありますので注意が必要です。 エスケープはOracle Databaseが用意するパッケージやメソッドを利用しなくても、カスタム開発で実装することも可能です。実際にここまで数回のSQLインジェクションの記事では、LIKE句による部分一致検索をおこなうときに特殊記号として利用する半角パーセント「%」、半角アンダーバー「_」やESCAPE句で特殊記号として指定する半角バックスラッシュ「\」をエスケープするためにreplaceAll関数を利用して文字を置き換えています。同じ要領でSQLインジェクションで利用される特殊記号をエスケープすればSQLインジェクション攻撃を防ぐことができますが、どの文字をエスケープすればよいかというのは場合によって異なります。半角シングルクォートをエスケープすればよいのはあくまで検索条件の文字列型として変数が指定されているときであり、たとえば検索条件が数字型の場合にはシングルクォートでは囲われていませんので、半角シングルクォートをエスケープするのではなく、変数に代入しようとしている値が数字かどうかのチェックが必要になります。 文字をエスケープしたり、データ型を確認したりとSQLインジェクションを起こさないようにサニタイズすることは不可能ではありませんが、確実にSQLインジェクションが起こらないようにするためには、さまざまな条件でそれぞれの対応をとる必要があり、深い知識が必要になります。また、特定の環境やバージョンのみで発生する新しいSQLインジェクションの手法が開発される可能性もあります。 万が一、考慮漏れがあった場合にはSQLインジェクションの被害を受ける可能性がありますので、可能な限りバインド変数の利用を推奨します。   「もくじ」にもどる

ここまではアプリケーションが発行するSQL文の構文がほぼ決まっているケースを紹介しました。しかし、アプリケーションによっては、検索条件列を自由に組み合わせられるなど、動的にSQL文が生成されるケースもあります。動的にSQL文を生成するケースでは文字列を連結してSQL文を生成することが多いです。このような場...

セキュリティ全般

Oracle Databaseセキュリティ・リスク・アセスメント

2016年2月10日にプレスリリースさせて頂いた「Oracle Databaseセキュリティ・リスク・アセスメント」ですが、 非常に多くのお客様からご相談を頂いているサービスになります。 本サービスは、「Oracle Database」を導入している企業を対象に、サイバー・セキュリティ対策をデータ保護の側面から支援するアセスメントになります。本アセスメントでは、以下を実施させて頂きます。  既存システムのデータベース設定に関する情報収集と分析 (Database Security Assessment Tool [DBSAT] を利用) オラクルの持つデータ・セキュリティ対策の標準的なベスト・プラクティスと比較して逸脱している項目を特定 業務アプリケーションやデータベースの運用管理者への聞き取り調査を通じて、すでに・対策されているシステムの運用・設定、利用技術において、潜在的なデータ漏えいのリスクにさらされている領域を特定 上記の分析を通じて、業務プロセスや既存のシステム設定変更、新しい技術の導入といった、セキュリティの改善計画の立案支援   ご興味のある方は、Oracle Digital にお問い合わせください。

2016年2月10日にプレスリリースさせて頂いた「Oracle Databaseセキュリティ・リスク・アセスメント」ですが、 非常に多くのお客様からご相談を頂いているサービスになります。 本サービスは、「Oracle Database」を導入している企業を対象に、サイバー・セキュリティ対策をデータ保護の側面から支援するアセスメントになります。本アセスメントでは、以下を実施させて頂きます。  既存シス...

データベースセキュリティ

[第43回] SQLインジェクションで被害を出さないためには

SQLインジェクション攻撃では、本来アクセス対象でない表からの情報漏えいが発生するだけでなく、全く関係ないSQL文を実行されてしまうものあります。 前回のエントリでも利用したSQLインジェクションが起きるWEBアプリケーションの検索条件に以下の文字列を入力するとどうなるでしょうか? '; drop table addrbook -- 以下のSQL文が生成され、実行されます。 select name from dbsecdemo.addrbook where name like '%'; drop table addrbook --%' 最後の「--%'」はコメントとして無視されるため、セミコロンで区切られた2つのSQL文となるのが分かります。単純に表を検索して結果を示すアプリで、まさかのDROP TABLE文がデータベースに送信されてしまいます。このように複数のSQL文を1命令にまとめたものを「複文(Multiple Statement)」と呼びます。Oracle Databaseでは基本的に複文をサポートしていないため、下記のようにエラーになりますが、複文をサポートしている環境ではSQLインジェクション攻撃によって想定外の表へのデータ改ざんや破壊が可能になるケースもあります。 ほかのデータベースで複文が利用できるかどうかは「SQL 複文」などで検索して確認してみてください。 SQLインジェクションで攻撃者がアクセスできる対象はそのアプリケーションが利用しているデータベースユーザーがアクセス権限を持っているものです。最小権限の原則の徹底が必要な理由はここにあります。万が一アプリケーションが利用しているデータベースユーザーにDBAロールやSELECT ANY TABLEのような強力なシステム権限が付与されている場合、データベースの中のすべてのデータが漏えいしてしまう危険があります。アプリケーション用のユーザーにそんなに強い権限を付与してしまうことなんてないと思われる方もいるかもしれません。しかし、残念ながら多くのお客様の本番環境でこのような強力な権限が付与されていることがDBSATを利用したセキュリティ・アセスメントサービスから事実としてわかっています。 アプリケーションが利用する表の所有者とアプリケーションから接続するユーザーを分けたほうがよいと第16回の「アプリケーション用のユーザー」で紹介しました。これも参照しかしないアプリケーションでSQLインジェクションが発生した場合、最小限の表への参照権限しか付与していないユーザーであれば、情報漏えいの被害は最小限に抑えられますが、もし表の所有者で接続していた場合、データを書き換えられたリアプリケーションで利用しているそのほかのすべての表の情報まで漏えいしてしまいます。商品カタログ参照アプリケーションで細かな条件で検索できるように複雑なプログラミングをした結果、SQLインジェクションが発生してしまうとしましょう。もし、商品カタログ用の商品データのみ参照できるデータベースユーザーを作成してそのユーザーで接続していた場合には被害の範囲はすべての商品データが参照されてしまうだけに限定されます。しかし、商品カタログを含む購買システムの表の所有者として接続していた場合には、すべての顧客情報が漏えいしてしまったり、発注データが書き換えられてしまったりする可能性もあります。 ここまで、SQLインジェクション対策として、以下のことを紹介してきました。 エラー情報を表示しない エラーが発生したことを監査ログなどから検知し対策する アプリケーションはバインド変数を利用する アプリケーション用のユーザーに過度の権限を付与しない これらの対策はSQLインジェクション以外の攻撃にも有効な対策になりますのでぜひ実施していただければと思います。 次回ももう少しSQLインジェクションの話を続けたいと思います。 「もくじ」にもどる

SQLインジェクション攻撃では、本来アクセス対象でない表からの情報漏えいが発生するだけでなく、全く関係ないSQL文を実行されてしまうものあります。 前回のエントリでも利用したSQLインジェクションが起きるWEBアプリケーションの検索条件に以下の文字列を入力するとどうなるでしょうか? '; drop table addrbook -- 以下のSQL文が生成され、実行されます。 select name...

データベースセキュリティ

[第42回] SQLインジェクションのおさらい

今回はSQLインジェクションのお話です。 SQLインジェクションが起きるサンプルページ自体はさすがに公開できないので、画面イメージだけになってしまいますが、どんなことが起きるのか、どうすれば防げるのかを説明します。 まず、サンプルのページの紹介です。今回、脆弱なWEBアプリケーションとして、検索で件数絞り込みができるJavaの住所録アプリを用意しました。 内部的は以下のようにSQLを発行して、条件に入れた文字がinStrに入って絞り込みをおこないます。 Statement stmt = conn.createStatement(); ResultSet rset = stmt.executeQuery("select name from dbsecdemo.addrbook where name like '%" + inStr + "%'"); 例えば、「田」と条件に入れると以下の条件のSQL文が生成され、結果として以下のようなページが生成されます。 select name from dbsecdemo.addrbook where name like '%田%' (2017年6月26日追記) このSQLだと、LIKE検索のワイルドカード文字である半角パーセント「%」や半角アンダーバー「_」を文字列として認識してくれません。この文章後半のSQLインジェクション対策ができているほうではきちんとこれらの文字をエスケープしていますが、こちらではエスケープしていませんでした。これらの文字をエスケープした書き方だと以下のようになります。 Statement stmt = conn.createStatement(); ResultSet rset = stmt.executeQuery("select name from dbsecdemo.addrbook where name like '%" + inStr.replaceAll("\\\\","\\\\\\\\").replaceAll("%","\\\\%").replaceAll("_","\\\\_") + "%' escape '\\'"); さて、実際に攻撃してみましょう。まず、ユーザーがアクセスできる表一覧を取得します。WEBアプリケーションの検索条件に下記の文字列を入力します。 xxxxxxxx' union select table_name from user_tables -- 発行されるSQL文は以下のようになります。 select name from dbsecdemo.addrbook where name like '%xxxxxxxx' union select table_name from user_tables --%' ここで、union句より前のSQL文は、「name like '%xxxxxxxx'」に合致するレコードはないため結果を戻さず、最後の「--%'」部分は、「--」はそれ以降はコメントとして扱うため無視されます。つまり、真ん中のselect table_name from user_tablesの結果が戻ります。 今回はADDRBOOK、APEX$TEAM_DEV_FILES、PRIVSという3つの表があることが分かります。今回は攻撃対象をADDRBOOK表とします。この表にどのような列があるのかを調べるために、WEBアプリケーションの検索条件に下記の文字列を入力します。 xxxxxxx' union select column_name from user_tab_columns where table_name='ADDRBOOK' -- ここでも同様にADDRBOOK表の列名を戻すselect column_name from user_tab_columns where table_name='ADDRBOOK'の結果が戻ります。 ここまでで攻撃者は表の構造が分かったので、最後にデータを取得するSQL文を含んだ下記の文字列をWEBアプリケーションの検索条件に入力します。 xxxxx' union select name || ', ' || address || ', ' || phone || ', ' || birthday from addrbook -- 本来アプリからは検索できないはずの情報まで画面に表示されてしまっています。 実際の攻撃ではもっとさまざまな内部構造を調査する必要があるでしょうが、基本的には上記のような問い合わせを繰り返して攻撃をおこない情報を搾取します。 SQLインジェクションの原因は、検索条件に入力した文字列をWEBアプリケーションが適切に処理していないため、データベースでSQLコマンドとして認識され、実行してしまうことです。今回のWEBアプリケーションではSQL文を作成する際に事前に用意した文字列とユーザーが検索条件として入力した文字列を単純に連結して、連結した文字列をデータベースにSQLコマンドとして送信して実行したことにあります。 ではどのWEBアプリケーションでSQLインジェクションが起きないようにするにはどうしたらよいでしょうか? 確実な方法は変数はプレースホルダとしてあとから指定し、SQL構文を事前にコンパイルしておくことです。簡単に言うと、PreparedStatementの利用を徹底することです。しかし、既存アプリケーションでPreparedStatementの利用が徹底されているかどうかをすべて確認することは難しいので、ここでは100%確実とは言えませんがSQLインジェクションが発生する可能性のあるページをあぶりだす方法の一つを紹介します。なお、この方法はペネトレーションテストでも利用しますが、実際のSQLインジェクション攻撃のための事前調査でも利用できる方法ですので、悪用はしないでください。 やることは簡単で、WEBアプリケーションの変数に半角シングルクォート「'」を入力します。 以下のようなSQL文が生成されますが、エラーとなってしまいます。 select name from dbsecdemo.addrbook where name like '%'%' 画面からはORA-00911エラーは発生します。同じSQLをSQL*Plusから実行するとORA-01756が発生します。 SQL> select name from dbsecdemo.addrbook where name like '%'%'; ERROR: ORA-01756: 引用符付き文字列が正しく終了していません 半角のシングルクォートは、文字の区切りに利用する文字です。この文字が正しく処理されないということはSQLインジェクションを起こす可能性があるサイトといえます。 ちなみにSQLインジェクション攻撃がちらほら出始めた2005年、ORA-01756やほかのデータベースで同様の意味のエラーをgoogleなどの検索エンジンで検索すると、SQLインジェクションの脆弱性があるであろうサイトがリストされたことがありました。アダルトサイトが多く、たぶんライセンス払ってないで勝手に使ってるんだろうなぁと思った記憶があります。アダルトサイトの利用者情報が漏えいしてしまうのは非常に怖いことですよね。 さて、ここまで攻撃について説明してきましたが、いよいよ防ぐ方法です。 もっとも確実な方法はSQLインジェクション攻撃が起きないアプリケーションを作成することですが、これは最後に説明します。 まずはアプリケーションのコーディングでミスがあっても、なるべく被害が発生しないようにする方法から説明します。 まずはエラー内容を画面に出さないことです。このアプリケーションではエラーが発生したときに画面にエラー内容が出てきてしまっています。攻撃者はこのエラー内容を頼りに脆弱性を探りあてて攻撃してきます。今回はエラー内容を文字列として画面に表示していますが、エラーハンドリングが正しくできておらずWEBサーバーなどのデフォルトのエラーページ(利用しているWEBサーバーのバージョン情報などもでてしまうことがあります)が、エンドユーザーや攻撃者に表示されてしまうことも避けましょう。ちなみに検索エンジンにはWEBサーバーのデフォルトのエラーページがたくさんリストされていましたが、ある時にすべて検索結果からエラーページは削除されたようです。 攻撃者に対して、エラー内容を戻さないことで攻撃の糸口を攻撃者に見せないことも重要ですが、エラーが発生したこと自体はシステム運用者がきちんと把握して、被害がでるまえに攻撃の予兆を確認したり、アプリケーションを修正していくことも同様に重要です。 ただし、アプリケーション側でエラーハンドリングをきちんと作りこんでいる場合、アプリケーションのエラーログが残らないこともありますので、データベース側でもアプリケーションが発行するSQL文でエラーが起きていないかどうか監査し、定期的に確認することが重要です。攻撃者はトライアンドエラーでシステムの脆弱性を探してきます。それぞれのシステムは固有のものであり、情報収集をするうえで、データベースエラーが発生してしまうことは多いです。しかし、それを監査し、定期的に確認しておかないと、攻撃者には無限の時間があることになり、いつかは攻撃は成功してしまいます。ユーザーやアプリケーションが発行するSQL文でエラーが発生することは多くはないはずなので、攻撃の予兆を被害が出る前に発見するためにもデータベースの監査と監視をおこなってください。 さて、最後にそもそもSQLインジェクションを起こさないアプリケーションの作り方です。 変数はプレースホルダとしてあとから指定し、SQL構文を事前にコンパイルしておく、つまりPreparedStatementを利用します。PreparedStatementを利用することで、SQLインジェクション攻撃は防げますが、今回のアプリケーションのようにLIKE検査をおこなう場合には、ユーザーの入力値の前後に部分一致検索用の半角パーセント「%」をつける必要があるのと、ユーザーが入力した半角パーセント「%」と半角アンダーバー「_」は任意文字を表してしまうのでエスケープする必要があります。具体的には以下のように記載します。 PreparedStatement pstmt = conn.prepareStatement("select name from dbsecdemo.addrbook where name like ? escape '\\'"); pstmt.setString(1, "%" + inStr.replaceAll("\\\\","\\\\\\\\").replaceAll("%","\\\\%").replaceAll("_","\\\\_") + "%"); ResultSet rset = pstmt.executeQuery(); 1行目ではSQL文のエスケープに半角バックスラッシュ「\」を利用することを宣言しています。ただし、「\」はJavaの文字列でもエスケープ文字として扱われるため2つ記載する必要があります。2行目でユーザーの入力値の前後に半角パーセント「%」をつけ、さらにユーザーの入力値内の半角パーセント「%」と半角アンダーバー「_」をエスケープします。replaceAllでそれぞれの文字をエスケープされた文字に置き換えますが、replaceAllでも「\」はエスケープ文字ですので、合計4つ「\\\\」と記載する必要があります。 (2017/6/22追記) 半角パーセント「%」と半角アンダーバー「_」のほかに半角バックスラッシュ「\」自身もエスケープする必要があります。エスケープしておかないと半角バックラッシュを含む文字列をユーザーが検索文字列に指定した際に「ORA-01424: エスケープ文字に続く文字がないか、または無効です。」エラーが発生することがあります。半角バックスラッシュをエスケープするため、上記のコードの中の紺いる文字の部分を追加しました。 このようにPreparedStatementを利用することで、半角シングルクォート「'」も文字列として扱われエラーは発生せず、またSQLインジェクション攻撃の文字列でも想定外のSQLが実行されることはありません。 次回もSQLインジェクション攻撃に関する話題の予定です。 「もくじ」にどもる  

今回はSQLインジェクションのお話です。 SQLインジェクションが起きるサンプルページ自体はさすがに公開できないので、画面イメージだけになってしまいますが、どんなことが起きるのか、どうすれば防げるのかを説明します。 まず、サンプルのページの紹介です。今回、脆弱なWEBアプリケーションとして、検索で件数絞り込みができるJavaの住所録アプリを用意しました。 内部的は以下のようにSQLを発行して、条件に入...

ID管理・認証

[第41回] 12cR2でのアカウント管理の強化

Oracle Database 12cR2のアカウント管理機能の新機能である、以下の2つの機能について説明します。 非アクティブなデータベース・ユーザー・アカウントの自動ロック 12cR2から一定期間ログインしていないユーザーを自動的にロックする機能が追加されました。自動的にロックするためにはパスワードプロファイルのINACTIVE_ACCOUNT_TIMEの値を設定します。INACTIVE_ACCOUNT_TIMEのデフォルト値はUNLIMITED(無制限)です。マニュアル上は一部デフォルト値が35(日)との表記もありますが、これはマニュアルの誤記載で正しいデフォルト値はUNLIMITEDです。現在マニュアルの修正を依頼しています。 パスワードプロファイル機能の一つですので、設定値はDBA_PROFILESビューから確認できます。 SQL> select profile, resource_name, limit from dba_profiles where resource_name='INACTIVE_ACCOUNT_TIME'; PROFILE -------------------------------------------------------------------------------- RESOURCE_NAME -------------------------------- LIMIT -------------------------------------------------------------------------------- DEFAULT INACTIVE_ACCOUNT_TIME UNLIMITED ORA_STIG_PROFILE INACTIVE_ACCOUNT_TIME 35 SAMPLE1 INACTIVE_ACCOUNT_TIME 15 パスワードの有効期限の設定(PASSWORD_LIFE_TIME)では有効期限(と猶予期間)が過ぎた後、アカウントはEXPIREDのステータスとなりますが、正しい古いパスワードでログインすると「ORA-28001: パスワードが期限切れです。」エラーが発生し、新しいパスワードを設定することでデータベースにログインすることはできます。一般的なアプリケーションでは「ORA-28001: パスワードが期限切れです。」エラーが発生した時点でエラーハンドリング処理に入ってしまい、結果としてデータベースにログインできず、アプリケーションとして正常に動作はしませんが、SQL*Plusなどの対話型のクライアントを利用している場合には、古いパスワードを知っていれば新しいパスワードを設定することでデータベースを継続的に利用することは可能です。それに対しINACTIVE_ACCOUNT_TIMEでは、設定期間アカウントが非アクティブであった場合、LOCKのステータスとなり、古いパスワードを知っていてもログインできなくなりますのでより安全です。 なお、12cR1からDBA_USERSビューにユーザーの最終ログイン時間を格納するLAST_LOGIN列が追加されています。また、自動的にロックされた場合、ロックされた日付はLOCK_DATE列に格納されます。 パスワードプロファイルに関しては、第10回「複雑なパスワードの強制 ~ パスワードプロファイル」もご参照ください。 管理ユーザーのパスワード管理強化 Oracle Databaseではパスワード認証を実施する際に一般ユーザーは内部表にパスワードを保持していますが、SYSなどAS SYSDBAキーワードをつけて接続する管理ユーザーのパスワードはデータベース内部の表ではなくパスワードファイルに保持します。12cR1まではパスワードファイルに特別な保護機能はありませんでしたが、12cR2ではパスワードファイルが拡張され管理ユーザーに対してもパスワードポリシーを設定できるようになりました。例えば、管理ユーザーのパスワードの複雑性ルールを設定したり、パスワードの有効期限、非アクティブ時の自動ロック、パスワード認証連続失敗時のアカウントロックなどをSYSユーザーに対しても実施できるようになりました。 SQL> connect sys@remotedb as sysdba パスワードを入力してください: ERROR: ORA-28000: アカウントがロックされています。 なお、ローカルホストでdbaグループに所属しているOSユーザーは、管理ユーザーとして接続する際にパスワード認証よりもOS認証が優先されますので、パスワードにどのような値を入力してもOSで認証されているためSYSユーザーとして接続できますのでご注意ください。 SQL> connect sys/wrong_password as sysdba 接続されました。 12cR2のDBCAで新しくデータベースを作成した場合、管理ユーザーに対するパスワード管理機能は有効になっていません。既存のパスワードファイルのformatパラメータの値は以下のorapwdコマンドで確認できます。 [oracle@catvari dbs]$ orapwd describe file=orapworcl Password file Description : format=12 また、V$PASSWORDFILE_INFOビューからも確認できます。 SQL> select * from v$passwordfile_info; FILE_NAME -------------------------------------------------------------------------------- FORMAT IS_AS CON_ID ------ ----- ---------- /opt/oracle/product/database/dbs/orapworcl 12 FALSE 0 この機能を利用するためにはパスワードファイルのformatパラメータを12.2に設定する必要があります。format=12.2のパスワードファイルを新しく作り直すこともできますが、既存のパスワードファイルをもとにformat=12.2のパスワードファイルに移行することもできます。移行のためにはorapwdコマンドのinput_fileパラメータを利用します。移行の手順は以下の通りです。 [oracle@catvari dbs]$ orapwd describe file=orapworcl Password file Description : format=12 [oracle@catvari dbs]$ mv orapworcl orapworcl.org [oracle@catvari dbs]$ orapwd file=orapworcl input_file=orapworcl.org format=12.2 [oracle@catvari dbs]$ orapwd describe file=orapworcl Password file Description : format=12.2 なお、formatパラメータのデフォルトは12.2であり、以下のようにformatパラメータを指定しないでorapwdコマンドを実行しても作成されるパスワードファイルはformat=12.2のものとなります。意図せずパスワードポリシーが有効になってしまう可能性がありますのでご注意ください。 [oracle@catvari dbs]$ orapwd file=orapworcl input_file=orapworcl.org [oracle@catvari dbs]$ orapwd describe file=orapworcl Password file Description : format=12.2 なお、データベースを起動した状態でパスワードファイルを書き換えただけではパスワードポリシーは有効化されず、何度ログイン失敗してもSYSユーザーはロックされず、パスワードポリシーを有効化するためにはデータベースの再起動が必要でした。 SYSユーザーがロックされてしまった場合には、ローカルホストでdbaグループに所属しているOSユーザーでOS認証を利用して管理者として接続する必要があります。SYSユーザーがロックされたからといってSYSユーザーとして完全にログインできなくなるわけではありません。 管理ユーザーに対するセキュリティレベルを上げる便利な新機能ですが、意図せずSYSユーザーがロックされてしまい業務に影響が出る可能性もありますので注意しつつ安全なデータベース運用を設計してください。 「もくじ」にもどる  

Oracle Database 12cR2のアカウント管理機能の新機能である、以下の2つの機能について説明します。 非アクティブなデータベース・ユーザー・アカウントの自動ロック 12cR2から一定期間ログインしていないユーザーを自動的にロックする機能が追加...

データベースセキュリティ

[第40回] セキュリティ関連の初期化パラメータ (6)

セキュリティ関連の初期化パラメータの説明の6回目です。 長かったこのシリーズもいよいよ最終回です。   SEC_PROTOCOL_ERROR_FURTHER_ACTION 11gR1から追加されたパラメータです。正常でないパケットを受け取った時の挙動を設定します。11gのデフォルト値はCONTINUEで、継続して正常なパケットを待ち続ける動作です。この状態ではデータベースサーバーは不正なパケットによってサービス妨害(DoS)攻撃を受ける可能性があります。12cからはデフォルト値が(DROP,3)に変更になりました。この場合、累積3つ正常でないパケットを受信すると、接続を強制的に切断します。サービス妨害(DoS)攻撃からサーバーを保護できますが、ネットワークが不安定な環境など、正規の通信でもパケットが壊れてしまった場合などは、強制切断されますのでトランザクションの再実行が必要などアプリケーションに影響がでる可能性もあります。通信が安定している環境では、12cのデフォルト値を利用することを推奨します。詳細は「不正パケット受信後のサーバー実行の制御」も併せてご確認ください。 SEC_PROTOCOL_ERROR_TRACE_ACTION 11gR1から追加されたパラメータです。正常でないパケットを受け取った時の挙動を設定します。デフォルト値はTRACEでデバッグをおこなうための詳細なトレースファイルが出力されます。不正なパケットが多くトレースファイルがストレージを圧迫することがなければ、デフォルトの値を利用することを推奨します。詳細は「プロトコル・エラーによってデータベースで受信した不正パケット」も併せてご確認ください。 SEC_RETURN_SERVER_RELEASE_BANNER 11gR1から追加されたパラメータです。認証中のクライアントに対してデータベースの詳細なバージョンを戻さないように設定できます。デフォルト値はFALSEで詳細なバージョン(PSRレベル)を戻しません。特別な理由がない限りはデフォルトの設定を利用することを推奨します。なお、SQL*Plusでは未認証時にデータベースのバージョンをクライアントに表示しない(認証が成功して初めて接続したデータベースのバージョンを表示する)ため、簡単にこのパラメータによる挙動の変更を確認することはできませんでした。詳細は「データベース・バージョン・バナーの表示構成」も併せてご参照ください。 SQL92_SECURITY Oracle Databaseでは、表に対してSELECT権限を持っていなくても、UPDATE、DELETE権限を持っている場合、UPDATE、DELETE文のWHERE句やSET句の中で暗黙的に表を参照することができました。しかし、この仕様はSQLの標準であるSQL92から外れていました。今までのオラクルのポリシーを適用するか、SQL92の標準に従うかをこのパラメータで制御できます。12cR2からデフォルト値がTRUEに変更になりました。設定がTRUEの場合、UPDATEやDELETEのWHERE句やSET句で表を参照する場合にはSELECT権限も併せて持つことが必要になります。12cR1までのデフォルト値であるFALSEの場合にはSELECT権限がなくてもUPDATEやDELETEのWHERE句やSET句で表を参照することができます。以下に簡単な例を示します。 まず、住所録を格納したAPP.ADDRBOOK表があるとします。表の定義は以下の通りです。 SQL> desc app.addrbook 名前 NULL? 型 ------------------------ -------- ---------------- ID NOT NULL NUMBER KANA_NAME VARCHAR2(64) SEX VARCHAR2(8) PHONE VARCHAR2(16) MAIL VARCHAR2(64) ZIP VARCHAR2(8) ADDRESS VARCHAR2(128) BIRTHDAY VARCHAR2(16) ユーザーはこの表に対して、SELECT権限は持っていないが、UPDATE権限を持っているとします。そのため、APP.ADDRBOOK表に対するSELECT文は権限不足エラーとなります。 SQL> select * from app.addrbook; select * from app.addrbook * 行1でエラーが発生しました。: ORA-01031: 権限が不足しています。 ここで、以下のようなUPDATE文を発行してみます。 SQL> update app.addrbook set KANA_NAME='' where SEX='男'; 57行が更新されました。 SQL92_SECURITY=FALSEの設定の場合、このSQL文は正常に実行できます。 ユーザーはAPP.ADDRBOOK表のデータを検索する権限はありませんが、この表には男性のデータが57件入っていることは分かってしまします。WHERE句でさらに条件を絞った問い合わせを実行することでどのようなデータが表に格納されているか推測することができてしまいます。これが推測攻撃と呼ばれるものです。SQL92_SECURITYをTRUEに設定しておけば、このようなUPDATE文をエラーで実行できないようにすることができます。 検索はできないようにしたいけど、更新はできるようにしたいというような特別な要件がない場合には、12cR2からのデフォルトのTRUEを設定することを推奨します。 UNIFIED_AUDIT_SGA_QUEUE_SIZE 12cR1で新しく追加されたパラメータですが、12cR2で非推奨となり、下位互換のために残されているパラメータです。 12cR1では、監査レコードはCommon Logging Infrastructure(CLI0の仕組みであるSGAキューを利用していました。このパラメータはそのキューのサイズを指定するものでしたが、12cR2からはデータベースの異常終了時の監査レコードのロスト防止とパフォーマンス向上のエンハンスのためSGAキューを利用しないようになりました。12cR2ではこのパラメータが設定されていないことを確認してください。 UTL_FILE_DIR UTL_FILEなどのPL/SQLパッケージプロシージャでファイルをI/Oするディレクトリを指定するパラメータですが、12cR2から非推奨となりました。このパラメータで指定したディレクトリのファイルはすべてのデータベースユーザーからPL/SQLパッケージプロシージャ経由で読み書き可能となりますので、注意が必要です。利便性のために「*(アスタリスク、すべてのディレクトリでファイルI/O許可)」の設定をしているシステムをよく見かけますが、最悪データファイルを上書きされ、データベースが破壊されてしまう危険性もありますので、指定するディレクトリには細心の注意が必要です。なお、UTL_FILEの代わりにデータベースユーザーごとに読み取り、書き込みなどの権限を詳細に設定できるディレクトリオブジェクトを利用するようにしてください。なお、古くは9iR2のマニュアルでも「UTL_FILE_DIRでなくCREATE DIRECTORY機能を使用してください」という記載があります。 _TRACE_FILES_PUBLIC SQLトレースなどのダンプのOSファイルのパーミッションはデフォルトではOSグループ以外のユーザー(others)からは読み書きできないようになっています。これはトレースファイルの中にデータベースの攻撃に利用できる情報やデータ自体が含まれている可能性があるからです。ただし、このパラメータを明示的にTRUEに設定することで、利便性のためにすべてのOSユーザーからトレースファイルにアクセスできるようにすることができます。特別な要件がない場合にはパラメータを設定しないようにしてください。 初期化パラメータを見るだけでも、Oracle Databaseがバージョンが上がるごとに新しいセキュリティ機能が追加されたり、より安全な初期設定に変更されてきていることが分かります。Oracle Databaseのバージョンアップは機能追加や性能向上だけではなく、セキュリティの向上にも寄与しています。 「もくじ」にもどる

セキュリティ関連の初期化パラメータの説明の6回目です。 長かったこのシリーズもいよいよ最終回です。   SEC_PROTOCOL_ERROR_FURTHER_ACTION 11gR1から追加...

データベースセキュリティ

[第39回] セキュリティ関連の初期化パラメータ (5)

セキュリティ関連の初期化パラメータの説明の5回目です。 REMOTE_LISTENER 別のコンピュータ上にあるリスナーにデータベースサービスを登録する際に利用するパラメータです。主にRAC環境で接続時フェイルオーバーや接続ロードバランシングを提供するために利用します。リモートリスナーに想定外のリスナーが設定されていると、そのリスナー経由で想定外のデータベースへの接続試行がおこなわれてしまいますので、想定されたリスナーが登録されているかどうかを確認してください。 REMOTE_LOGIN_PASSWORDFILE 管理者としての接続(SYSDBAなど)時にパスワードファイルを利用するかどうかを指定します。パスワードファイルがない場合やパラメータの値をNONEに設定した場合には、データベースを起動するために管理者として接続する際にOS認証を利用する必要があります。パスワードを利用して接続しようとしても、下記のようにエラーとなります。 [puku@catvari ~]$ sqlplus sys/oracle as sysdba SQL*Plus: Release 12.2.0.1.0 Production on 水 5月 17 10:31:21 2017 Copyright (c) 1982, 2016, Oracle. All rights reserved. ERROR: ORA-01017: ユーザー名/パスワードが無効です。ログオンは拒否されました。 パスワードを利用して認証する場合、データベースサーバーのOSにdbaグループのユーザーとしてログインすることなく管理ツールなどを利用して管理者として接続しデータベースを管理することができ、運用性が向上します。Enterprise Managerなどの管理ツールを利用する場合など、パスワードファイルの利用が前提条件になっているものもあります。逆にパスワードファイルを利用しないことで、強力な管理者として接続するためにはOSのdbaグループのユーザーとしてまずOSにログインしなければならないという強力な接続制限ができるようになります。このパラメータの値に関しては第5回「データベース管理者と認証」でも紹介していますのでご参照ください。 REMOTE_OS_AUTHENT このパラメータは11gR1から非推奨で、下位互換のために残されているパラメータです。デフォルトはFALSEですが、TRUEに設定されている場合、リモートホストのOS認証を信頼し、OS認証でデータベースに接続できるようになります。たとえばリモートホストでoracleユーザーとしてログインしている場合、ローカルホストのoracleユーザーと同一とみなされ、改めて認証されることなく管理者として接続できてしまう可能性があります。特別な必要性がない限りは値を設定しない(FALSEを設定する)ことを推奨します。 REMOTE_ROLES REMOTE_OS_AUTHENTと併せて利用するパラメータでリモートホストからのOS認証だけではなく権限(ロール)の付与もリモートホストに移譲する機能です。OS_ROLESパラメータのリモートホスト版になります。なりすましの危険性があるためこのパラメータのデフォルト値もFALSEです。特別な必要性がない限りは値を設定しない(FALSEを設定する)ことを推奨します。 RESOURCE_LIMIT プロファイルのリソース制限を実施するかどうかを指定します。デフォルトはTRUEですが、FALSEに設定している場合、リソース制限は実施されません。プロファイルのリソース制限を利用して特定のプロセスの暴走などでデータベース全体に影響を与えないようサービス拒否攻撃対策を実施している場合には、併せてこのパラメータがFALSEに設定されていないことを確認してください。 SEC_CASE_SENSITIVE_LOGON 11gR1から追加されたパラメータですが、12cR1から非推奨で、下位互換のために残されているパラメータです。 Oracle Databaseでは11gR1からデータベースユーザーのパスワードを大文字、小文字区別するようになりました。デフォルト値はTRUEでデフォルトの状態では大文字と小文字を区別します。ただし、パスワードの大文字、小文字を区別しない古いプログラムやツールにも対応できるように、このパラメータをFALSEに変更するとパスワードの大文字、小文字を区別しない昔の動作に戻すことができます。近年のプログラムやツールはパスワードの大文字、小文字を区別できるものがほとんどですので、特別な必要性がない限りは設定しない(TRUEを設定する)ことを推奨します。 SEC_MAX_FAILED_LOGIN_ATTEMPTS 11gR1から追加されたパラメータです。パスワード推測攻撃によるログイン試行は一昔前は同じデータベースユーザーに対してパスワードを次々変えてログイン試行するものでした。この場合、一定回数以上パスワードを間違えるとアカウントをロックするという対策がとれましたが、パスワードを固定してデータベースユーザー名を次々に変えてログイン試行をする新しいパターンの攻撃が見受けられるようになりました。この場合、接続を試みるデータベースユーザーが異なるためユーザーはロックされません。このような攻撃に対応するために、複数回ログインに失敗すると接続を強制的に切断する機能が11gR1から追加されました。パラメータの値で指定した回数接続に失敗すると接続は切断されます。デフォルト値は11gでは10でしたが、12cから3に変更になりました。不必要に大きな値になっていないかどうか確認してください。また、この設定は攻撃を遅らせるだけで、攻撃を防止したり、検地したりすることはできません。ログイン失敗を監査・監視して不正なログイン試行に気づく仕組みは別途必要です。詳細は「認証の最大試行回数の構成」も併せてご確認ください。 「もくじ」にもどる

セキュリティ関連の初期化パラメータの説明の5回目です。 REMOTE_LISTENER 別のコンピュータ上にあるリスナーにデータベースサービスを登録する際に利用するパラメータです。主にRAC環境で接続時フェイルオーバーや接続ロードバランシングを提供するために利用します。リモートリスナーに想定外のリスナーが設定されていると、そのリスナー経由で想定外のデータベースへの接続試行がおこなわれてしまいますので、...

データベースセキュリティ

[第38回] セキュリティ関連の初期化パラメータ (4)

セキュリティ関連の初期化パラメータの説明の4回目です。 LDAP_DIRECTORY_ACCESS Oracle Databaseでは、ユーザーの認証にLDAPディレクトリを利用することもできます。この機能はEnterprise User Security(12cR2英語マニュアル、12cR1日本語マニュアル)と呼ばれ、Enterprise Editionの基本機能として利用可能です。このパラメータはユーザーをディレクトリで認証する際にどのような認証方法を利用するかを指定します。ディレクトリを利用しないNONE、パスワードによる認証をおこなうPASSWORD、SSLによる認証をおこなうSSLの値をとります。Enterprise User Securityは個人IDを利用してデータベースにアクセスすることができる便利な機能ですが、利用できるディレクトリはOracle Internet DirectoryとOracle Unified Directoryに限られていますので注意が必要です。利用していないのに想定外の値が設定されていないかどうか確認してください。 LDAP_DIRECTORY_SYSAUTH 管理ユーザー(SYSDBAおよびSYSOPER)の認証でディレクトリを利用する場合には、このパラメータをyesに設定します。 あくまで追加で作成したSYSDBA権限を持つユーザーであって、SYSユーザーをディレクトリで認証するわけではないのでご注意ください。詳細は「管理ユーザーのディレクトリ認証の構成」も併せてご確認ください。利用していないのに想定外の値が設定されていないかどうか確認してください。 O7_DICTIONARY_ACCESSIBILITY 古いバージョンのOracle Database(Oracle 7)では、SELECT ANY TABLEシステム権限などANYキーワードを持つ強力なシステムを持っている場合、SYSスキーマ内の内部表にもアクセスすることができました。つまり、たとえばパスワードハッシュを含むUSER$表にもアクセス可能でした。その後、セキュリティ強化のためANYシステム権限でSYSスキーマのオブジェクトへのアクセスは禁止されましたが、下位互換のためにこのパラメータをTRUEに設定した場合、セキュリティレベルを弱めてANYシステム権限でSYSスキーマのオブジェクトにアクセスできるようになります。デフォルト値はFALSEで、SYSスキーマのオブジェクトにはアクセスできません。特別な要件がない限りにはTRUEに変更しないでください。 OS_AUTHENT_PREFIX Oracle Databaseでは、ユーザー認証をOSに移譲する、外部認証機能があります。この機能を利用するとOSで認証されたユーザーはデータベースで改めて認証することなくデータベースに接続できますが、その際にマッピングされるデータベースユーザー名はこのOS_AUTHENT_PREFIXの値にOSのユーザー名が続いたものになります。例えばOSユーザー名がpukuで、OS_AUTHENT_PREFIXがデフォルトのOPS$の場合、事前にデータベースにOPS$PUKUという外部認証されるデータベースユーザーを作成しておくことで、OSにpukuでログインすれば再度認証することなくデータベースにOPS$PUKUユーザーとして接続することができます。詳細は「ユーザーのオペレーティング・システム認証」も併せてご確認ください。この機能はデータベースサーバー上にアプリケーションを作成し、ユーザーはデータベースサーバーのOSにログインしてそこからアプリケーションを起動して、アプリケーションはネットワークを介さずにデータベースに接続するような構成が一般的だった時代に便利に利用されてきた機能です。現在のネットワークを介してデータベースに接続する環境ではめったに利用する機会がない機能です。利用していないのに想定外の値が設定されていないかどうか確認してください。 OS_ROLES このパラメータはOS認証機能と併せて利用し、認証だけではなく権限(ロール)の付与もOSに移譲する機能です。このパラメータをTRUEに設定するとデータベースユーザーに対するロールの割り当てを、OSで管理することができるようになります。詳細は「オペレーティング・システムまたはネットワークを使用したロールの付与」をご確認ください。この機能はデータベースサーバー上にアプリケーションを作成し、ユーザーはデータベースサーバーのOSにログインしてそこからアプリケーションを起動して、アプリケーションはネットワークを介さずにデータベースに接続するような構成が一般的だった時代に便利に利用されてきた機能です。現在のネットワークを介してデータベースに接続する環境ではめったに利用する機会がない機能です。利用していないのに想定外の値が設定されていないかどうか確認してください。 PDB_LOCKDOWN 12cR2から追加された初期化パラメータです。PDBごとにユーザーが実行できる操作を制限するロックダウンプロファイルを指定することができます。ロックダウンプロファイルには、AQやパーティションなどのオプション利用の制限、UTL_FILEやUTL_SMTPパッケージなどを利用したネットワークやOSへのアクセスの制限、ALTER DATABASE、ALTER SYSTEM、ALTER SESSIONなどのSQL実行の制限を設定することができます。これらの制限をおこなうことでPDBがOSやネットワークを介してほかのPDBのデータにアクセスできないようにし、PDBごとの独立性を保証できます。詳細は「PDBロックダウン・プロファイルの概要」も併せてご確認ください。 PDB_OS_CREDENTIAL 12cR2から追加された初期化パラメータです。通常PDBからOS操作をおこなう際にはOSのoracleインストール(実行)ユーザー権限で処理がおこなわれます。しかし、一般的にこのユーザーは強力な権限を持っており、このOSユーザーの権限を利用することでPDBからOS経由で別のPDBのデータにアクセスされてしまう危険性があります。PDBごとにPDB_OS_CREDENTIALパラメータにOSユーザーを指定することで、そのPDBからOS操作をおこなう際に指定したOSユーザー権限を利用して操作をおこなうことができ、結果としてPDBごとの独立性を保証することができます。 「もくじ」にもどる

セキュリティ関連の初期化パラメータの説明の4回目です。 LDAP_DIRECTORY_ACCESS Oracle Databaseでは、ユーザーの認証にLDAPディレクトリを利用することもできます。この機能はEnterprise User Security(12cR2英語マニュアル、12cR1日本語マニュアル)と呼ばれ、Enterprise Editionの基本機能として利用可能です。このパラメータは...

データベースセキュリティ

[第37回] セキュリティ関連の初期化パラメータ (3)

セキュリティ関連の初期化パラメータの説明の3回目です。   DISPATCHERS    共有サーバー(SHARED SERVER)構成で利用するディスパッチャ・プロセスを構成するためのパラメータです。共有サーバー構成に関しては津島博士のパフォーマンス講座の第23回「共有サーバー構成について」を参照して下さい。 XMLDBを構成している環境では、「(PROTOCOL=TCP) (SERVICE=<データベースSID名>XDB)」という値が設定されていることが多いです。XMLDBの機能を利用すると、HTTP(S)、FTPなどのサービスを利用できます。たとえばEM Expressを構成するとデフォルトでは5500番ポートでHTTPS通信を待ち受けます。待ち受けポートの設定と確認はDBMS_XDB_CONFIGパッケージのファンクションを利用したSQLやEnterprise ManagerのXMLDB構成の画面からおこなうことができます。 SQL> select dbms_xdb_config.getftpport,   2         dbms_xdb_config.gethttpport,   3         dbms_xdb_config.gethttpsport   4    from dual; GETFTPPORT GETHTTPPORT GETHTTPSPORT ---------- ----------- ------------          0           0         5500 ポートを待ち受けていない場合には、戻り値は0となります。待ち受けポートの設定も同じくDBMS_XDB_CONFIGパッケージのプロシージャで設定できます。 XMLDBの全ての構成の確認をおこないたい場合には、以下のSQLを実行して下さい。 set pagesize 50000 set long 999999 select dbms_xdb_config.cfg_get() from dual; また、lsnrctlコマンドからもOracle Databaseが待ち受けに使っているポートを確認できます。 [oracle@catvari ~]$ lsnrctl status LSNRCTL for Linux: Version 12.2.0.1.0 - Production on 06-4月 -2017 10:30:21 Copyright (c) 1991, 2016, Oracle.  All rights reserved. (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=catvari.jp.oracle.com)(PORT=1521)))に 接続中 リスナーのステータス ------------------------ 別名                      LISTENER バージョン                TNSLSNR for Linux: Version 12.2.0.1.0 - Production 開始日                    05-4月 -2017 13:08:09 稼働時間                  0 日 21 時間 22 分 12 秒 トレース・レベル          off セキュリティ              ON: Local OS Authentication SNMP                      OFF パラメータ・ファイル      /opt/oracle/product/database/network/admin/listener.ora ログ・ファイル            /opt/oracle/diag/tnslsnr/catvari/listener/alert/log.xml リスニング・エンドポイントのサマリー...   (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=catvari.jp.oracle.com)(PORT=1521)))   (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))   (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=catvari.jp.oracle.com)(PORT=5500))(Security=(my_wallet_directory=/opt/oracle/admin/orcl/xdb_wallet))(Presentation=HTTP)(Session=RAW))   (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=catvari.jp.oracle.com)(PORT=8080))(Presentation=HTTP)(Session=RAW)) サービスのサマリー... サービス"4c65400cde0f1ff5e053b49bb90ae4fb.jp.oracle.com"には、1件のインスタンス があります。   インスタンス"orcl"、状態READYには、このサービスに対する1件のハンドラがあります... サービス"appdb.jp.oracle.com"には、1件のインスタンスがあります。   インスタンス"orcl"、状態READYには、このサービスに対する1件のハンドラがあります... サービス"orcl.jp.oracle.com"には、1件のインスタンスがあります。   インスタンス"orcl"、状態READYには、このサービスに対する1件のハンドラがあります... サービス"orclXDB.jp.oracle.com"には、1件のインスタンスがあります。   インスタンス"orcl"、状態READYには、このサービスに対する1件のハンドラがあります... コマンドは正常に終了しました。  不要なポート、想定外のポートでの通信の待ち受けをしていないかどうか確認して下さい。     ENCRYPT_NEW_TABLESPACES 12cR2から新しく追加されたパラメータです。 新しく作成する表領域をデフォルトで暗号化するかどうかを指定できます。デフォルト値はCLOUD_ONLYでこれはOracle Cloud環境では暗号化されますが、オンプレミス環境では暗号化されないモードです。オンプレミス環境でも常に暗号化したい場合にはALWAYSを指定して下さい。なお暗号化アルゴリズムはAES128で固定となります。また、暗号化自体はOracle Advanced Securityオプションの透過的データ暗号化(TDE:Transparent Data Encryption)を利用しますので、オンプレミス環境のデータベースでこのパラメータを利用する場合には、オプションライセンスと事前に透過的データ暗号化機能を利用するための事前準備(暗号鍵の作成)が必要となります。Oracle Cloud環境ではどのStandardを含むエディションでも暗号化機能を利用することができます。    GLOBAL_NAMES このパラメータの値がTRUEに設定されている場合、データベースリンクを作成するときに、データベースリンク名が接続するデータベースと同じである必要があります。データベースリンクを利用する際にはこのパラメータをTRUEに設定して、データベースリンクの命名規則を強制し、想定外のデータベースに接続されないように運用をすることが推奨されています。 「もくじ」にもどる

セキュリティ関連の初期化パラメータの説明の3回目です。   DISPATCHERS    共有サーバー(SHARED SERVER)構成で利用するディスパッチャ・プロセスを構成するためのパラメータです。共有サーバー構成に関しては津島博士のパフォーマンス講座の第23回「共有サーバー構成について」を参照して下さい。 XMLDBを構成している環境では、「(PROTOCOL=TCP) (SERVICE=<データベー...

データベースセキュリティ

[第36回] セキュリティ関連の初期化パラメータ (2)

セキュリティ関連の初期化パラメータの説明の2回目です。 COMPATIBLE 下位互換を保証するためのパラメータです。アップグレード後に何らかの理由でダウングレードをおこなう際に利用する事もありますが、特別な事情がない限りは最新のセキュリティ機能が利用できる利用しているバージョンと同じ値を設定すべきです。この値を変更せずにアップグレードしたからといって、オプティマイザ含め古いバージョンと動作が変わらないことを保証するものではないため、アップグレード前のテストをおこなわなくてよくなるような魔法のパラメータではありません。   DBFIPS_140 12cR1から追加されたパラメータで、米国標準技術研究所(NIST)の米国連邦情報処理標準(FIPS)の暗号モジュールに関するセキュリティ要件の標準である140-2にあわせてデータベースを構成するためのパラメータです。透過的データ暗号化(TDE:Transparent Data Encryption)、DBMS_CRYPTOパッケージプロシージャ、Oracle Net通信の暗号化利用時に、FIPS 140-2に準拠した暗号化アルゴリズム、ハッシュアルゴリズムしか利用できなくなります。デフォルト値はfalseです。 このパラメータを変更すると、暗号化処理時に利用するライブラリが認定されたものに変わります。利用されるライブラリなど詳細は「セキュリティ・ガイド」マニュアルの付録「E Oracle Database FIPS 140-2の設定」をご参照ください。 なお、このパラメータを変更することにより、以下の影響を受ける可能性がありますのでご注意ください。   性能への影響 FIPS 140-2対応のライブラリは非対応のライブラリに比べてロードに時間がかかります。各プロセスが最初に暗号化処理を実施するときに暗号化ライブラリをロードする際にオーバーヘッドがあります。ひとつひとつのオーバーヘッドは無視できるレベルかもしれませんが、コネクションプールを利用しないで専用接続(DEDICATED SERVER)構成の大量の接続処理がある場合には注意が必要です。なお、このオーバーヘッドは最初に暗号化処理を実施するときのみで、一度ライブラリがロードされた後の暗号化処理性能への影響はありません。この内容はMy Oracle Support(MOS)のドキュメントID2191845.1「When Library is loaded after setting DBFIPS_140」として公開されています。   対応アルゴリズムの制限 FIPS 140-2に対応ために、Oracle Databaseでマニュアルに利用できると記載されている暗号化アルゴリズム、HASHアルゴリズムのうち、非推奨(弱い)とされているものは利用できなくなります。これは暗号化ライブラリにはそのアルゴリズムがそもそも入っていないためです。たとえば、ハッシュアルゴリズムのうちMD5は利用できなくなり、利用しようとすると以下のようにエラーとなります。 SQL> declare   2    vText varchar2(16) := 'hoge';   3    vHashed raw(256);   4  begin   5    vHashed := dbms_crypto.hash(utl_i18n.string_to_raw(vText,  'al32utf8'),   6                                dbms_crypto.hash_md5);   7    dbms_output.put_line(vHashed);   8  end;   9  / declare * 行1でエラーが発生しました。: ORA-28817: PL/SQLファンクションからエラーが戻されました。 ORA-06512: "SYS.DBMS_CRYPTO_FFI", 行131 ORA-06512: "SYS.DBMS_CRYPTO", 行72 ORA-06512: 行5 DBFIPS_140パラメータをtrueに設定すると、既存のシステムやパッケージアプリケーションが動作しなくなるケースもあるためご注意ください。非推奨のアルゴリズムを実際に利用していなくても、内部的に非推奨のアルゴリズムを「使ってもよい」ことになっているだけで動作しなくなることもあります。たとえばオラクルの機能でもAPEX(Application Express)でDBFIPS_140パラメータをtrueに設定できるのは5.0以降であることがMy Oracle Support(MOS)のドキュメントID2097020.1「APEX and FIPS 140」として公開されています。 暗号化に関しての詳細はまた別エントリで今後説明する予定です。 「もくじ」にもどる    

セキュリティ関連の初期化パラメータの説明の2回目です。 COMPATIBLE下位互換を保証するためのパラメータです。アップグレード後に何らかの理由でダウングレードをおこなう際に利用する事もありますが、特別な事情がない限りは最新のセキュリティ機能が利用できる利用しているバージョンと同じ値を設定すべきです。この値を変更せずにアップグレードしたからといって、オプティマイザ含め古いバージョンと動作が変わらな...

データベースセキュリティ

[第35回] セキュリティ関連の初期化パラメータ (1)

DBSATレポートの「Database Configuration」セクションの「Initialization Parameters for Security」は、その名の通りセキュリティ関連の初期化パラメータがリストされます。     このセクションでセキュリティ関連の初期化パラメータとしてリストされるものは以下の30個です。今回からそれぞれのパラメータを説明していきます。   AUDIT_FILE_DEST AUDIT_SYSLOG_LEVEL AUDIT_SYS_OPERATIONS AUDIT_TRAIL COMPATIBLE DBFIPS_140 DISPATCHERS ENCRYPT_NEW_TABLESPACES GLOBAL_NAMES LDAP_DIRECTORY_ACCESS LDAP_DIRECTORY_SYSAUTH O7_DICTIONARY_ACCESSIBILITY OS_AUTHENT_PREFIX OS_ROLES PDB_LOCKDOWN PDB_OS_CREDENTIAL REMOTE_LISTENER REMOTE_LOGIN_PASSWORDFILE REMOTE_OS_AUTHENT REMOTE_OS_ROLES RESOURCE_LIMIT SEC_CASE_SENSITIVE_LOGON SEC_MAX_FAILED_LOGIN_ATTEMPTS SEC_PROTOCOL_ERROR_FURTHER_ACTION SEC_PROTOCOL_ERROR_TRACE_ACTION SEC_RETURN_SERVER_RELEASE_BANNER SQL92_SECURITY UNIFIED_AUDIT_SGA_QUEUE_SIZE UTL_FILE_DIR _TRACE_FILES_PUBLIC   今回は監査関連のパラメータを説明します。なお、マニュアルもリンクしますので詳細はマニュアルを参照して下さい。なるべくマニュアルに記載されていない情報を書くようにします。   AUDIT_FILE_DEST 監査証跡をファイル出力(OS、XML)に設定している場合の出力ディレクトリを設定します。デフォルト監査、標準監査、ファイングレイン監査、DBA監査(SYS監査)の監査証跡を出力します。また、Data Guardのスタンバイなどデータベースが読み取り専用状態の場合、監査証跡の出力先をデータベースに指定していても、このディレクトリにファイル出力されます。 DBSATレポートの「Auditing」セクションの「Audit Records」にも設定値が表示されます。   AUDIT_SYSLOG_LEVEL DBA監査(SYS監査)および出力先がOSの場合の標準監査をSYSLOGに出力します。標準監査の出力がOSの場合、実行されたSQL文本文が取得できなかったり、12cからの統合監査(Unified Auditing)に対応していなかったりと、下位互換のために残されている感の強いパラメータです。 DBSATレポートの「Auditing」セクションの「Audit Records」にも設定値が表示されます。   AUDIT_SYS_OPERATIONS 特権(SYSASM、SYSBACKUP、SYSDBA、SYSDG、SYSKMまたはSYSOPER権限)を利用して接続しているユーザーによって直接発行されたトップレベルSQLを監査しOSファイルに出力します。DBA監査(SYS監査)機能と呼ばれます。標準監査の出力がXML形式に指定している場合、DBA監査の出力もXML形式となります。標準監査、ファイングレイン監査ではSYSユーザーの操作は監査対象外なので、SYSユーザーの操作を監査するためにはこのDBA監査機能を利用するか、12c以降の統合監査(Unified Auditing)を利用する必要があります。デフォルト値はTRUEですが、FALSEに変更されているシステムを良く見かけます。 DBSATレポートの「Auditing」セクションの「Administrative User Audit」にも設定値が表示されます。AUDIT_SYS_OPERATIONSの値がfalseで、かつ統合監査(Unified Auditing)でSYSユーザーの監査をしていない場合、Significant Riskと判断されます。   AUDIT_TRAIL 標準監査の出力先を指定します。標準監査の監査証跡はデータベース内に出力するよりもXMLにファイル出力したほうが性能がよい(オーバーヘッドが小さい)という検証結果もあり、またSQL文本文を監査証跡に残せるため推奨値はxml,extendedですが、12c以降では統合監査(Unified Auditing)を利用することを推奨します。デフォルト値はnoneですが、11gR1以降のDatabase Configuration Assistant(DBCA)で作成したデータベースでは初期設定としてdbが設定されます。 DBSATレポートの「Auditing」セクションの「Audit Records」にも設定値が表示されます。AUDIT_TRAILの値がnoneの場合、Significant Riskと判断されます。 監査に関しての詳細はまた別エントリで今後説明する予定です。   「もくじ」にもどる

DBSATレポートの「Database Configuration」セクションの「Initialization Parameters for Security」は、その名の通りセキュリティ関連の初期化パラメータがリストされます。     このセクションでセキュリティ関連の初期化パラメータとしてリストされるものは以下の30個です。今回からそれぞれのパラメータを説明していきます。   AUDIT_FILE_D...

ID管理・認証

[第34回] Oracle Databaseが作成するユーザー一覧

第21回「デフォルトで最初から作成されているユーザー」で事前定義のユーザーに関してどのように運用していくかの考え方を説明しましたが、そもそも現在のデータベースの中でどのユーザーがOracle Databaseが作成するユーザーなのか、マニュアルにリストがありますので紹介します。 11gR2 「Oracle Databaseから提供される事前定義されるユーザー・アカウント」 12cR1 「Oracle Databaseから提供される事前定義されるユーザー・アカウント」 12cR2 「Oracle Databaseから提供される事前定義されるユーザー・アカウント」 Oracle Database 12cR1 (12.1.0.2)以降ではDBA_USERSデータディクショナリビューが拡張され、オラクルが内部的に利用しているユーザーかどうかを確認するためのORACLE_MAINTAINEという列が追加されました。この列の値がYのユーザーは オラクル社が提供するスクリプト(catalog.sqlやcatproc.sqlなど)以外の方法で変更しないでください。 SQL> select username, oracle_maintained from dba_users; USERNAME                       O ------------------------------ - SYS                            Y SYSTEM                         Y XS$NULL                        Y AAA                            N OUTLN                          Y DBSNMP                         Y APPQOSSYS                      Y DBSFWUSER                      Y GGSYS                          Y ANONYMOUS                      Y GSMADMIN_INTERNAL              Y XDB                            Y WMSYS                          Y GSMCATUSER                     Y APP1                           N  (後略) デフォルトで作成されるアカウントは利用しているかどうか分からないため、ロックしたときの影響がわからないのでロックできない場合には、マニュアルに記載されている各アカウントの用途からロック可能かどうかを判断してください。 なお、本当にそのユーザーが利用されていないかどうかを細かく確認したいときには、有償オプションになりますが、Oracle Database Vaultの権限分析(Privilege Analysis)機能(12cR2英語マニュアル、12cR1日本語マニュアル)が利用できます。この機能は12cR1からの新機能ですが詳細はまた別のエントリで。  「もくじ」にもどる

第21回「デフォルトで最初から作成されているユーザー」で事前定義のユーザーに関してどのように運用していくかの考え方を説明しましたが、そもそも現在のデータベースの中でどのユーザーがOracle Databaseが作成するユーザーなのか、マニュアルにリストがありますので紹介します。 11gR2 「Oracle Databaseから提供される事前定義されるユーザー・アカウント」 12cR1 「Oracle D...

アクセス制御

[第33回] 仮想プライベートデータベース (7) ~ 12cR2での動作変更に注意 (DBMS_SESSION.IS_ROLE_ENABLED)

さて、このブログの仮想プライベートデータベースのエントリは12cR2を使って実行して、実行結果を貼り付けているのですが、その過程で12cR2で12cR1までと挙動が変わっているところを発見してしまいました。想定される動作かどうか開発に確認したのですが、どうやら新しい動作がセキュリティ的には正しい動作らしく、ただし、データベースをアップグレードすると挙動が変わってしまう可能性もあるのでご注意ください。 具体的には、ポリシーファンクションでDBMS_SESSION.IS_ROLE_ENABLEDファンクション(12cR2英語マニュアル、12cR1日本語マニュアル)を利用できなくなりました。DBMS_SESSION.IS_ROLE_ENABLEDファンクションはロール名を引数にとり、ユーザーがそのロールを保有しているかどうか(現在有効かどうか)をBOOLEAN(TRUE/FALSE)で戻すファンクションです。 12cR1までは、特定のデータベースロール(MYROLE)を保有しているユーザーであれば値を見れるようにしたい場合、以下のようなポリシーファンクションを作成し、実現することができました。 create or replace function app1.vpdsamplefunc   (v_schema varchar2, v_objname varchar2)   return varchar2 is begin   if dbms_session.is_role_enabled('myrole') then     return '1=1';   else     return '0=1';   end if; end; /  12cR2ではこのようなポリシーファンクションを作成した場合、DBMS_SESSION.IS_ROLE_ENABLEDファンクションは常にFALSEを戻します。 これはポリシーファンクションは常に定義者権限で実行されるためです。ポリシーファンクションは実行者権限で作成することはできません。(実行者権限で定義しても定義者権限で実行されます) そして、PL/SQLの仕様で定義者権限で実行されるプログラムではPUBLICロールのみが有効化された状態で実行されます。そのため、DBMS_SESSION.IS_ROLE_ENABLEDファンクションで引数にユーザーが定義したロールを指定しても常にFALSEが戻ります。 ポリシーファンクションは定義者権限で実行されるという仕様は昔からあったのですが、12cR1まではDBMS_SESSION.IS_ROLE_ENABLEDファンクションで実行者に割り当てられているロールによってTRUEを戻していました。12cR2では定義者権限で実行されるプログラムではPUBLICロールのみが有効化されるという正しい動作に修正され、結果として常にFALSEを戻すようになりました。  では、仮想プライベートデータベースでロールベースのアクセス制御ができなくなってしまったかというと、そうではありません。たとえば次のようにポリシーを作成することで、先ほどのポリシーファンクションと同等の結果を戻すことが確認できました。   12cR2の現時点での最新バージョンで確認していますが、将来的にまた動作が変わる可能性があることはご了承ください    create function aaa.has_role (x varchar2) return varchar2 is begin   if dbms_session.is_role_enabled(x) then return 'TRUE';   else return 'FALSE';   end if; end; / create or replace function aaa.vpdfunc   (v_schema varchar2, v_objname varchar2)   return varchar2 is begin   return 'aaa.has_role(''myrole'') =''TRUE'''; end; / 今回、私が気付いたのはDBMS_SESSION.IS_ROLE_ENABLEDファンクションの挙動の変更ですが、他のファンクションも定義者権限で実行されますので、実行者の権限を利用しようとしているものは挙動が変わる可能性があります。VPDを利用しているシステムを12cR2にアップグレードする際にはご注意ください。 「もくじ」にもどる  

さて、このブログの仮想プライベートデータベースのエントリは12cR2を使って実行して、実行結果を貼り付けているのですが、その過程で12cR2で12cR1までと挙動が変わっているところを発見してしまいました。想定される動作かどうか開発に確認したのですが、どうやら新しい動作がセキュリティ的には正しい動作らしく、ただし、データベースをアップグレードすると挙動が変わってしまう可能性もあるのでご注意くだ...

アクセス制御

[第32回] 仮想プライベートデータベース (6) ~ 列レベルのアクセス制御

前回までは仮想プライベートデータベースで行レベルのアクセス制御を実現する方法を説明してきました。 今回は列レベルのアクセス制御を実現する方法を説明します。 列レベルのアクセス制御を実現するには、ファイングレインアクセスコントロール設定時にDBMS_RLS.ADD_POLICYプロシージャでsec_relevant_colsとsec_relevant_cols_optパラメータを設定します。 まずSYSTEMユーザーでデータベースに接続し、列レベルのアクセス制御の確認用にAPP1.TESTTAB表に行を追加します。 alter table app1.testtab add (mynumber varchar2(12)); さて、ここでMYNUMBER列に値を追加したいのですが、どのユーザーであれば値が追加できるでしょうか?  正解はSYSユーザーだけです。値を追加するには表に対するUPDATE権限が必要ですが、オブジェクトオーナーであるAPP1ユーザーもUPDATE ANY TABLEシステム権限を持っているSYSTEMユーザーも仮想プライベートデータベースのアクセス制御の設定でデータが参照できなくなっています。そのため、データの更新もできません。唯一、SYSユーザーはUPDATE ANY TABLEシステム権限を持ち、仮想プライベートデータベースのアクセス制御ポリシーをバイパスできるSYSユーザーだけが値を追加できます。 マイナンバーは事務取扱担当者しかアクセスしてはいけないため、今回は事務取扱担当者用のユーザー(NAGISA)を追加し、このユーザーでMYNUMBER列に値を追加することにします。  create user nagisa identified by Orac1el2c; grant create session to nagisa; grant select, update on app1.testtab to nagisa; ファイングレインアクセスコントロールのポリシーファンクションを変更して、事務取扱事業者のNAGISAユーザーもメンテナンスユーザーのPUKUユーザーと同じ条件で全行のデータを見れるようにします。  create or replace function app1.vpdfunc   (v_schema varchar2, v_objname varchar2)   return varchar2 is begin   if upper(sys_context('userenv','session_user')) in ('PUKU', 'NAGISA') then     if sys_context('userenv','ip_address') = '10.185.155.180' and        sys_context('userenv','client_program_name') like 'sqlplus%' then       return '1=1';     else       return '0=1';     end if;   elsif upper(sys_context('userenv','session_user')) = 'APP1USER' then     if sys_context('userenv','client_program_name') = 'dbsecnavi sample application' then       return 'name = upper(sys_context(''userenv'',''client_identifier''))';     else       return '0=1';     end if;   else     return 'name = upper(sys_context(''userenv'',''session_user''))';   end if; end; /  NAGISAユーザーでデータベース接続すると、MYNUMBER列に値を追加できます。 update app1.testtab set mynumber = '123456789012' where name='SATO'; update app1.testtab set mynumber = '234567890123' where name='ITO'; commit; NAGISAユーザーでデータが追加されていることを確認します。 SQL> select * from app1.testtab; NAME             MYNUMBER ---------------- ------------ SATO             123456789012 ITO              234567890123 さて、メンテナンスユーザーのPUKUユーザーは事務取扱担当者ではないので、MYNUMBER列にはアクセスできないようにしなくてはなりません。MYNUMBER列へのアクセスは事務取扱担当者のみに制限します。ここではSATO、ITOユーザーも自分のMYNUMBERデータにもアクセスできないような制限をかけます。新しく事務取扱担当者のNAGISAユーザーだけがMYNUMBER列にアクセスできるというポリシーファンクションを作成します。ファンクションを作成するためにSYSTEMユーザーでデータベースに接続し直す必要があります。 create or replace function app1.mynumberfunc   (v_schema varchar2, v_objname varchar2)   return varchar2 is begin   if upper(sys_context('userenv','session_user')) = 'NAGISA' then     return '1=1';   else     return '0=1';   end if; end; / 最後にファイングレインアクセスコントロールのポリシーを作成します。 begin   dbms_rls.add_policy(     object_schema => 'app1',     object_name => 'testtab',     policy_name => 'sample_colpol',     function_schema => 'app1',     policy_function => 'mynumberfunc',     sec_relevant_cols => 'mynumber',     sec_relevant_cols_opt => dbms_rls.all_rows); end; / これでメンテナンスユーザーのPUKUユーザーは 全件見えるけれどもMYNUMBER列は見えず、MYNUMBER列が見れるのは事務取扱担当者のNAGISAユーザーだけというアクセス制御が実現できます。 SYSTEMユーザーで接続 SQL> show user ユーザーは"SYSTEM"です。 SQL> select * from app1.testtab; レコードが選択されませんでした。 SATOユーザーで接続 SQL> show user ユーザーは"SATO"です。 SQL> select * from app1.testtab; NAME             M ---------------- - SATO PUKUユーザー(メンテナンスユーザー)で接続 SQL> show user ユーザーは"PUKU"です。 SQL> select * from app1.testtab; NAME             M ---------------- - SATO ITO NAGISAユーザー(事務取扱担当者)で接続 SQL> show user ユーザーは"NAGISA"です。 SQL> select * from app1.testtab; NAME             MYNUMBER ---------------- ------------ SATO             123456789012 ITO              234567890123 既存のアプリケーションに手を入れずに特定の列を見せないようにする便利な機能ですが、アクセス権限がない場合に戻る値はNULLです。アプリケーション側でNULL値が戻った時の挙動を適切にハンドリングしていないと、エラーになったり、NULLという文字列が表示されてしまったりする可能性もあるのでご注意ください。 「もくじ」にもどる

前回までは仮想プライベートデータベースで行レベルのアクセス制御を実現する方法を説明してきました。 今回は列レベルのアクセス制御を実現する方法を説明します。 列レベルのアクセス制御を実現するには、ファイングレインアクセスコントロール設定時にDBMS_RLS.ADD_POLICYプロシージャでsec_relevant_colsとsec_relevant_cols_optパラメータを設定します。 まずSYS...

アクセス制御

[第31回] 仮想プライベートデータベース (5) ~ WEBアプリケーションユーザーごとのアクセス制御

かなり前置きが長くなりましたが、いよいよ仮想プライベートデータベースでWEBアプリケーションごとのアクセス制御を実施してみます。今回はWebLogic Serverを利用しますので、第14回の「実際の利用者をデータベースに伝播する ~ セッション情報」でも紹介した「接続時にクライアントIDを設定」機能を利用することで、特別なコーディングなく実現できます。 それでは実際にWEBアプリケーションの実行結果から見てみましょう。 satoでログイン itoでログイン アプリ実行画面右上ヘッダ部分ににアプリケーションユーザー名が表示されています。これはrequest.getRemoteUser()メソッドで取得したWeblogic Serverで認証されたユーザーの名前です。 アプリ本文の上から3行はデータベースのセッション情報です。上から順番にsys_context('userenv','session_user')で取得した接続データベースユーザー名、sys_context('userenv','client_identifier')で取得したクライアント識別子、sys_context('userenv','client_program_name')で取得したプログラム名を表示しています。 その下にAPP1.TESTTAB表への絞り込み条件を指定しないSQL文(select name from app1.testtab)で取得した結果を表形式で表示しています。 このアクセス制御を実現するためのファイングレインアクセスコントロールのポリシーファンクションは第30回の「仮想プライベートデータベース (4) ~ アプリケーションユーザーごとのアクセス制御の実装方法」で作成したものをそのまま利用しています。データベースには手を加えずに、WEBアプリケーションを開発してWebLogic Serverにデプロイしただけです。WebLogic Server側のユーザー認証の設定に関する詳しい説明はこのブログでは省略しますが、今回WebLogic Serverで実施した作業は以下の通りです。   ユーザーとグループの追加 satoとitoのふたりのユーザーを追加して、新しく作成したvalid_userというグループのメンバーに登録しました。 データソースの追加 JNDI名が「jdbc/dbsecnavi」というデータソースを作成しました。データベースにはAPP1USERで接続し、プログラム名は「dbsecnavi sample application」とし、「接続時にクライアントIDを設定」機能を利用するための設定をおこないました。 アプリケーションのデプロイ 参考までにJDevelopperで作成したアプリケーションのソースを公開します。私はプログラミングは得意ではない(どこかからサンプルプログラムを探して、コピペ・編集してアプリを作るレベル)なので、ソースコードが読みづらい部分もあるとは思いますがご了承ください。   アプリケーションのデプロイ後、デプロイしたサーバーの/dbsecnaviにアクセスするとメニューページが表示され、「vpd sample application」をクリックすると、ログイン画面を経て、最初に紹介したアプリケーションのページが表示されます。 メニューページ さて、ここまでの手順でアプリケーションユーザーごとのアクセス制御は実現できたのですが、このままではアプリケーション用のAPP1USERでSQL*Plusを利用してデータベースに接続されてしまうと、DBMS_SESSION.SET_IDENTIFIERプロシージャで自由にユーザー名を設定されて、結局すべてのユーザーになりすまされてデータを見られてしまいます。最後にアプリケーションユーザーであっても、今回作成したアプリケーション以外にはデータを戻さないように制限をかけるようにファイングレインアクセスコントロールのポリシーファンクションを変更します。追加したコードは赤字で示した部分です。 create or replace function app1.vpdfunc   (v_schema varchar2, v_objname varchar2)   return varchar2 is begin   if upper(sys_context('userenv','session_user')) = 'PUKU' then     if sys_context('userenv','ip_address') = '10.185.155.180' and        sys_context('userenv','client_program_name') like 'sqlplus%' then       return '1=1';     else       return '0=1';     end if;   elsif upper(sys_context('userenv','session_user')) = 'APP1USER' then     if sys_context('userenv','client_program_name') = 'dbsecnavi sample application' then       return 'name = upper(sys_context(''userenv'',''client_identifier''))';     else       return '0=1';     end if;   else     return 'name = upper(sys_context(''userenv'',''session_user''))';   end if; end; / 上記の設定でSQL*PlusからAPP1USERで接続されても、アプリのデータは見れなくなりました。 仮想プライベートデータベースを利用して、データベース側にアクセス制御ポリシーを保持するメリットは、すべてのアプリケーションで同一のアクセス制御ポリシーを抜け漏れなく適用できる点です。今回は表にアクセスするページは1ページだけのアプリケーションでしたが、画面が増えれば増えるほど、データへのアクセスは単純なSQL文ですむことのメリットは大きくなります。とくにアクセス制御ポリシーの変更を求められるケースでは、アプリケーション側でアクセス制御ポリシーを実装していると変更しなければいけない個所が多くなりすぎて、改修コストが増大したり、場合によっては改修し忘れてセキュリティホールとなってしまうかもしれません。 たとえば、マイナンバーの運用が始まった時にマイナンバーは限定された人しか見れないようにしなければならないというルールができました。ひとつの表のなかに様々な個人情報とともにマイナンバーも格納されている場合、マイナンバー列だけは限られた人しか見れないようにしなければなりません。 たとえば、個人情報保護法改正で何が個人情報にあたるかが厳密に定義され、「特定の個人を識別できるメールアドレス」も個人情報であり保護する必要があることになっています。今後はメールアドレスも業務上必要な時以外は見れないように保護する必要があります。 次回はこのようなケースに対応するための、仮想プライベートデータベースの列レベルのアクセス制御について説明します。 「もくじ」にもどる  

かなり前置きが長くなりましたが、いよいよ仮想プライベートデータベースでWEBアプリケーションごとのアクセス制御を実施してみます。今回はWebLogic Serverを利用しますので、第14回の「実際の利用者をデータベースに伝播する ~ セッション情報」でも紹介した「接続時にクライアントIDを設定」機能を利用することで、特別なコーディングなく実現できます。 それでは実際にWEBアプリケーションの実行結...

アクセス制御

[第30回] 仮想プライベートデータベース (4) ~ アプリケーションユーザーごとのアクセス制御の実装方法

さて今回は仮想プライベートデータベースを利用してアプリケーションユーザーごとのアクセス制御を実現してみましょう。 アプリケーションユーザー名の識別には、このブログの第14回「実際の利用者をデータベースに伝播する ~ セッション情報」で紹介したクライアント識別子(Client Identifier)を利用します。 では、データベースに必要な設定をおこなっていきます。 まずはアプリケーションが利用するデータベースユーザーの作成です。今回はAPP1USERというユーザーを作成して、APP1.TESTTAB表へのアクセス権限を付与します。 create user app1user identified by oracle; grant create session to app1user; grant select on app1.testtab to app1user;  上記ユーザーの作成はアプリケーション用のユーザーに簡単なパスワードをつけている悪い例です。 次にファイングレインアクセスコントロールのポリシーファンクションの変更です。 今回は接続ユーザーがAPP1USERの場合には、アプリケーションユーザー(クライアント識別子)のデータのみ戻す設定をおこないます。フローチャートは省略しますが、ファンクションには以下の赤字の2行を追加するだけです。 create or replace function app1.vpdfunc   (v_schema varchar2, v_objname varchar2)   return varchar2 is begin   if upper(sys_context('userenv','session_user')) = 'PUKU' then     if sys_context('userenv','ip_address') = '10.185.155.180' and        sys_context('userenv','client_program_name') like 'sqlplus%' then       return '1=1';     else       return '0=1';     end if;   elsif upper(sys_context('userenv','session_user')) = 'APP1USER' then     return 'name = upper(sys_context(''userenv'',''client_identifier''))';   else     return 'name = upper(sys_context(''userenv'',''session_user''))';   end if; end; /  では実際にアクセスしてみましょう。 まずはAPP1USERでデータベースに接続します。 SQL> connect app1user/oracle@appdb 接続されました。 ログイン直後のデフォルトの状態では、クライアント識別子に値は設定されていません(NULLが設定されています)。 SQL> select sys_context('userenv','client_identifier') from dual; SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') -------------------------------------------------------------------------------- クライアント識別子に値が設定されていない場合、APP1.TESTTAB表にアクセスしてもファイングレインアクセスコントロールによって条件「NAME = ''」が付加されますので結果は戻りません。 SQL> select * from app1.testtab; レコードが選択されませんでした。  次にクライアント識別子をSATOに設定します。SQL*Plus上でクライアント識別子を設定するには、DBMS_SESSIONパッケージのSET_IDENTIFIERプロシージャ(12cR2英語マニュアル、12cR1日本語マニュアル)を実行します。 SQL> execute dbms_session.set_identifier('sato') PL/SQLプロシージャが正常に完了しました。  クライアント識別子に値が正しく設定されたことを確認します。 SQL> select sys_context('userenv','client_identifier') from dual; SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') -------------------------------------------------------------------------------- sato  クライアント識別子にSATOという値が設定されている場合、ファイングレインアクセスコントロールによって「NAME = 'SATO'」という条件が付加されますので、1行の結果が戻ります。 SQL> select * from app1.testtab; NAME ---------------- SATO  次にクライアント識別子をITOに設定し、値を確認します。 SQL> execute dbms_session.set_identifier('ito') PL/SQLプロシージャが正常に完了しました。 SQL> select sys_context('userenv','client_identifier') from dual; SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') -------------------------------------------------------------------------------- ito  現在はクライアント識別子がITOという値に設定されているため、先ほどとは異なる結果が戻ります。 SQL> select * from app1.testtab; NAME ---------------- ITO  クライアント識別子をクリアするにはDBMS_SESSIONパッケージのCLEAR_IDENTIFIERプロシージャ(12cR2英語マニュアル、12cR1日本語マニュアル)を実行します。プロシージャを実行すると、クライアント識別子の値は設定されていない状態となり、表を検索しても結果は戻らなくなります。 SQL> execute dbms_session.clear_identifier PL/SQLプロシージャが正常に完了しました。 SQL> select sys_context('userenv','client_identifier') from dual; SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') -------------------------------------------------------------------------------- SQL> select * from app1.testtab; レコードが選択されませんでした。 次回はいよいよWEBアプリケーションでアプリケーションユーザーごとのアクセス制御を実装します。 「もくじ」にもどる

さて今回は仮想プライベートデータベースを利用してアプリケーションユーザーごとのアクセス制御を実現してみましょう。 アプリケーションユーザー名の識別には、このブログの第14回「実際の利用者をデータベースに伝播する ~ セッション情報」で紹介したクライアント識別子(Client Identifier)を利用します。 では、データベースに必要な設定をおこなっていきます。まずはアプリケーションが利用するデータ...

アクセス制御

[第29回] 仮想プライベートデータベース (3) ~ 複雑なポリシーの作り方

前回はデータベースユーザーごとに同じ表への全件検索でも同じ結果を戻す仮想プライベートデータベースの設定方法を説明しました。しかし、現実のアプリケーションではアクセス制御のルールはこうも簡単ではありません。たとえば前回の設定ではアプリケーションのデータをメンテナンスしようとしても、すべてのデータを見れる人がいない状態です。  アクセス制御のルールを作成するうえで重要なことは、どのようなルールなのかを明確に定義することです。必要最小限のデータしか見れないようにするというのは大前提ですが、必要最小限ではあいまいすぎます。どのような場合にどのデータにアクセスさせるか仮想プライベートデータベースではポリシーファンクションとして実装する必要がありますので、プログラムを前提として仕様を決める必要があります。この点を抑えていないと、アクセス制御の抜け道ができたり、新しいアクセス制御のルールの追加時にどのようにポリシーファンクションを変更すればよいのかが分からなくなってしまいます。 では実際にアクセス制御のルールを考えていきましょう。 まず、メンテナンス用のユーザーを考えます。メンテナンス用のユーザーは全件にアクセスできます。ただしいつでもどこからでもどのプログラムを利用してもデータにアクセスできてしまうのは危険なので、たとえば特定の端末から特定のプログラムを利用した場合のみアクセス可能とします。 それ以外の一般ユーザーは引き続き自分のデータにしかアクセスできないことにします。 フローにすると下記の通りです。   あとはフローにしたがってコーディングするだけです。 create or replace function app1.vpdfunc   (v_schema varchar2, v_objname varchar2)   return varchar2 is begin   if upper(sys_context('userenv','session_user')) = 'PUKU' then     if sys_context('userenv','ip_address') = '10.185.155.180' and        sys_context('userenv','client_program_name') like 'sqlplus%' then       return '1=1';     else       return '0=1';     end if;   else     return 'name = upper(sys_context(''userenv'',''session_user''))';   end if; end; / ユーザー名、IPアドレス、プログラム名等を調べるときは事前に以下のSQLを発行したり、V$SESSIONビューを確認したりしてください。 select sys_context('userenv','session_user'),        sys_context('userenv','ip_address'),        sys_context('userenv','client_program_name')   from dual; 実行例 SQL> select sys_context('userenv','session_user'),   2         sys_context('userenv','ip_address'),   3         sys_context('userenv','client_program_name')   4    from dual; SYS_CONTEXT('USERENV','SESSION_USER') -------------------------------------------------------------------------------- SYS_CONTEXT('USERENV','IP_ADDRESS') -------------------------------------------------------------------------------- SYS_CONTEXT('USERENV','CLIENT_PROGRAM_NAME') -------------------------------------------------------------------------------- PUKU 10.185.155.180 sqlplus@catvari.jp.oracle.com (TNS V1-V3) ファイングレインアクセスコントロールのポリシーを作成し、結果を確認してみましょう。 ポリシーの作成 begin   dbms_rls.add_policy(     object_schema => 'app1',     object_name => 'testtab',     policy_name => 'sample_vpdpol',     function_schema => 'app1',     policy_function => 'vpdfunc'); end; / SYSTEMからは見えるデータはありません。 SQL> show user ユーザーは"SYSTEM"です。 SQL> select * from app1.testtab; レコードが選択されませんでした。 SATOとITOは自分のデータのみ参照できます。 SQL> connect sato@appdb パスワードを入力してください: 接続されました。 SQL> select * from app1.testtab; NAME ---------------- SATO SQL> connect ito/hoge@appdb 接続されました。 SQL> select * from app1.testtab; NAME ---------------- ITO メンテナンスユーザー(PUKU)は特定の端末の特定のアプリからはアクセス可能ですが、それ以外からはアクセスできません。 管理用端末からアクセス SQL> select sys_context('userenv','session_user'),   2         sys_context('userenv','ip_address'),   3         sys_context('userenv','client_program_name')   4    from dual; SYS_CONTEXT('USERENV','SESSION_USER') -------------------------------------------------------------------------------- SYS_CONTEXT('USERENV','IP_ADDRESS') -------------------------------------------------------------------------------- SYS_CONTEXT('USERENV','CLIENT_PROGRAM_NAME') -------------------------------------------------------------------------------- PUKU 10.185.155.180 sqlplus@catvari.jp.oracle.com (TNS V1-V3) SQL> select * from app1.testtab; NAME ---------------- SATO ITO それ以外の端末からアクセス SQL> select sys_context('userenv','session_user'),   2         sys_context('userenv','ip_address'),   3         sys_context('userenv','client_program_name')   4    from dual; SYS_CONTEXT('USERENV','SESSION_USER') -------------------------------------------------------------------------------- SYS_CONTEXT('USERENV','IP_ADDRESS') -------------------------------------------------------------------------------- SYS_CONTEXT('USERENV','CLIENT_PROGRAM_NAME') -------------------------------------------------------------------------------- PUKU 10.185.155.204 sqlplus@dbsec.jp.oracle.com (TNS V1-V3) SQL> select * from app1.testtab; レコードが選択されませんでした。  なお、ポリシーファンクションで戻り値が条件句の形式をとっていないなどのエラーが発生した場合には、SQL文実行時に下記のエラーが戻ります。ポリシーファンクションを修正して下さい。 SQL> select * from app1.testtab; select * from app1.testtab                    * 行1でエラーが発生しました。: ORA-28113: ポリシー述語にエラーがあります。   今回は仮想プライベートデータベースで管理者は全件アクセスできるというポリシーを実現するためのポリシーファンクションを作成しました。しかし、今回まではデータベースユーザーごとのアクセス制御をおこなっています。次回はコネクションプールを利用したアプリケーションユーザーごとにアクセス制御をおこなう方法を紹介します。 「もくじ」にもどる    

前回はデータベースユーザーごとに同じ表への全件検索でも同じ結果を戻す仮想プライベートデータベースの設定方法を説明しました。しかし、現実のアプリケーションではアクセス制御のルールはこうも簡単ではありません。たとえば前回の設定ではアプリケーションのデータをメンテナンスしようとしても、すべてのデータを見れる人がいない状態です。  アクセス制御のルールを作成するうえで重要なことは、どのようなルールなのかを明...

アクセス制御

[第28回] 仮想プライベートデータベース (2) ~ ポリシーを設定してみよう

さて、いよいよ12cR2が入手可能になりましたね! というわけで、このブログでもサンプルの実行は12cR2上でおこなおうと思います。 それにともない、マニュアルの参照先も12cR2のマニュアルにしたかったのですが、一部まだ翻訳されていないものもあるようなので、しばらく日本語マニュアルを優先するために、12cR1のマニュアルを参照することもあるのでご了承ください。 では、前回紹介したデータベースユーザーによって結果が変わる設定はどのようにおこなうかを説明します。 今回はAPP1スキーマのTESTTAB表に対するアクセス制御を実施しています。APP1スキーマのTESTTAB表は以下のSQL文で作成するNAMEというひとつの列をもつ表です。 create table app1.testtab (name varchar2(16)); 今回はこの表にSATOとITOという2行のレコードが入っています。 insert into app1.testtab values ('SATO'); insert into app1.testtab values ('ITO'); この状態ではアクセス権限を持っているユーザーが表にアクセスすると、2行のデータが戻ります。 SQL> show user ユーザーは"SYSTEM"です。 SQL> select * from app1.testtab; NAME ---------------- SATO ITO  ファイングレインアクセスコントロールを設定するためには、あらかじめポリシーファンクションと呼ばれるアクセス制御条件を戻すファンクションを作成しておく必要があります。つまりWHERE句に内部的に自動的に追加したい条件をもどすファンクションを作成します。今回はNAME列がデータベースユーザー名と同じかどうかという条件をもどすファンクションを作成します。データベースユーザー名は第11回のセッション情報の回で紹介したSYS_CONTEXT関数で取得できます。 今回は「name = sys_context('userenv','session_user')」という文字列をもどすファンクションを作成すればよいことになります。ポリシーファンクションは戻り値は上記の文字列をVARCHAR2型でもどしますが、ファンクションを作成する際に必ず表の所有者と表の名前の2つのVARCHAR2型の引数をとる必要があります。ファンクションを作成する際には以下のように2つのVARCHAR2型の引数とVARCHAR2型の戻り値を定義します。 create or replace function app1.vpdfunc   (v_schema varchar2, v_objname varchar2)   return varchar2  さて、ファンクションの本体は今回は非常に簡単です。以下の1行だけです。 return 'name = sys_context(''userenv'',''session_user'')';  SYS_CONTEXT関数の引数で利用するシングルクォートをエスケープしなければならないことに注意して下さい。 ということで、ポリシーファンクションは以下のように作成します。 create or replace function app1.vpdfunc   (v_schema varchar2, v_objname varchar2)   return varchar2 is begin   return 'name = upper(sys_context(''userenv'',''session_user''))'; end; /  では、作成したポリシーファンクションを適用していきましょう。ファイングレインアクセスコントロールの設定にはDBMS_RLSパッケージプロシージャ(12cR2英語マニュアル、12cR1日本語マニュアル)を利用します。ファイングレインアクセスコントロールのポリシーを作成するにはADD_POLICYプロシージャを実行します。 ADD_POLICYプロシージャで最低限必要な引数を利用したポリシーを作成するコマンドは以下の通りです。ポリシーを設定する対象の表、ポリシー名、ポリシーファンクションをそれぞれ指定します。コマンドの実行にはDBMS_RLSパッケージプロシージャの実行権限が必要ですが、今回は簡単のためにSYSTEMユーザーで実行します。 begin   dbms_rls.add_policy(     object_schema => 'app1',     object_name => 'testtab',     policy_name => 'sample_vpdpol',     function_schema => 'app1',     policy_function => 'vpdfunc'); end; /  では、表にアクセスしてみましょう。 SQL> show user ユーザーは"SYSTEM"です。 SQL> select * from app1.testtab; レコードが選択されませんでした。 SYSTEMユーザーでアクセスした場合でも、内部的に自動的に条件句が追加されることによって、レコードが戻らなくなった事が確認できます。もちろんSYSTEMユーザーは作成したポリシーを削除することができるため、データベース管理者に対するアクセス制御として仮想プライベートデータベースを利用することはできません。なお、SYSユーザーの場合は仮想プライベートデータベースのポリシーをバイパスし全てのデータに引き続きアクセスできます。 SQL> show user ユーザーは"SYS"です。 SQL> select * from app1.testtab; NAME ---------------- SATO ITO  それでは本題の一般ユーザーから表にアクセスしてみましょう。 今回はSATOとITOというデータベースユーザーをあらかじめ作成していますが、これらのユーザーに表へのSELECT権限が別途必要である事は変わらないため、事前に付与しておいてください。 grant select on app1.testtab to sato,ito; まずはSATOで接続し、表にアクセスしてみます。  SQL> connect sato@appdb パスワードを入力してください: 接続されました。 SQL> select * from app1.testtab; NAME ---------------- SATO  次にITOで接続し、表にアクセスしてみます。 SQL> connect ito@appdb パスワードを入力してください: 接続されました。 SQL> select * from app1.testtab; NAME ---------------- ITO  それぞれデータベースユーザー名と同じデータしか見れなくなった事を確認できます。 さて、次回は実際の運用に沿ったもう少し細かい仮想プライベートデータベースの利用方法を説明します。 ただし、その前にひとつ、今のままだと表のデータにアクセスできないままなので、作成したポリシーの削除方法だけ紹介しておきます。ポリシーの削除はDBMS_RLSパッケージのDROP_POLICYプロシージャを利用します。 begin   dbms_rls.drop_policy(     object_schema => 'app1',     object_name => 'testtab',     policy_name => 'sample_vpdpol'); end; /  このプロシージャを実行できるのは、デフォルトではデータベース管理者で一般ユーザーでは実行できない事に注意して下さい。一般ユーザーで実施してもDBMS_RLSパッケージの実行権限がないため、そのようなパッケージはないとエラーになります。 ここまで書いてきて、まったく12cR2っぽくないので、最後にバナーを。 [oracle@catvari ~]$ sqlplus system/oracle@appdb SQL*Plus: Release 12.2.0.1.0 Production on 金 3月 3 13:59:19 2017 Copyright (c) 1982, 2016, Oracle.  All rights reserved. 最終正常ログイン時間: 金 3月  03 2017 13:58:09 +09:00 Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production に接続されました。 SQL>  これは、管理者のパスワードが脆弱な悪い例です。  「もくじ」にもどる

さて、いよいよ12cR2が入手可能になりましたね! というわけで、このブログでもサンプルの実行は12cR2上でおこなおうと思います。 それにともない、マニュアルの参照先も12cR2のマニュアルにしたかったのですが、一部まだ翻訳されていないものもあるようなので、しばらく日本語マニュアルを優先するために、12cR1のマニュアルを参照することもあるのでご了承ください。 では、前回紹介したデータベースユーザー...

データベースセキュリティ

Oracle Database 12c Release 2 オンプレミス版がリリース

Oracle Database 12c Release (12.2) のオンプレミス版の Linux x86-64, SPARC, Intel Solaris. 版が出荷されました。 ※ ダウンロード先: Oracle Software Delivery Cloud  セキュリティについても実装・運用面での機能強化を図っていますので、是非ご確認下さい。  ・オンラインでの既存表領域暗号化  ・オフラインでの既存表領域暗号化(11gR2, 12cR1にパックパート済)   ・Database Vault のシュミレーションモード  ・基本機能の強化(管理者アカウントの認証強化, ログオンされていないユーザーのロック等) 詳細な機能紹介については、昨年実施したOracle DBA & Developer Days 2016 の以下の資料を確認下さい。 [DD3-5] Oracle Database 12c : セキュリティ新機能でデータベースをより強固に守る なお、その他のプラットフォームの出荷も順次予定しております。予定は、MOS Note:742060.1 をご確認下さい。

Oracle Database 12c Release (12.2) のオンプレミス版の Linux x86-64, SPARC, Intel Solaris. 版が出荷されました。 ※ ダウンロード先: Oracle Software Delivery Cloud  セキュリティについても実装・運用面での機能強化を図っていますので、是非ご確認下さい。  ・オンラインでの既存表領域暗号化  ...

アクセス制御

[第27回] 仮想プライベートデータベース (1) ~ 仮想プライベートデータベースとは

データベースへのアクセス制御は、システム権限、オブジェクト権限やそれをまとめたロールを利用しておこなうことを以前のエントリで説明しました。これらの権限で実施できるアクセス制御の最小の単位は「表」です。ひとつの表のなかのどのデータにアクセスできるかは権限では制限できません。 Oracle DatabaseのEnterprise Editionでは、より詳細な表の行や列単位でのアクセス制御をおこなうために、仮想プライベートデータベース(VPD:Virtual Private Database)というソリューションを提供しています。仮想プライベートデータベースを利用することで、たとえばひとつの表に複数のユーザーのデータがまとめて入っているような場合でも、それぞれのユーザーが表に全件検索を実施した時に自分のデータしか結果としてもどらないようなアクセス制御を実現できます。人や時間、クライアント端末、アプリなどのアクセス条件によって、同じ表に同じSQL文を発行した場合でも、異なる結果を戻すことができます。  仮想プライベートデータベースはファイングレインアクセスコントロール(Fine-Grained Access Control)という機能を利用して実現されています。ファイングレインアクセスコントロールは、SQLの実行時に内部的に自動的にWHERE句の絞り込み条件を追加する機能です。ファイングレインアクセスコントロールで内部的に自動的にWHERE句が付け加えられることにより、全件検索のSQL文を実行しても、事前に定義された絞り込み条件に合致するデータのみが結果として戻ります。 たとえば、以下の例ではSATOというデータベースユーザーとITOというデータベースユーザーで接続して、同じAPP1スキーマのTESTTAB表に全件検索を実施していますが、ユーザーごとに結果が変わっているのが分かります。これは内部的にWHERE句が付け加えられて、絞り込みが実施されたためです。 SQL> connect sato@appdb パスワードを入力してください: 接続されました。 SQL> select * from app1.testtab; NAME ---------------- SATO SQL> connect ito@appdb パスワードを入力してください: 接続されました。 SQL> select * from app1.testtab; NAME ---------------- ITO 実際の設定方法は次回のエントリで説明します。 「もくじ」にもどる

データベースへのアクセス制御は、システム権限、オブジェクト権限やそれをまとめたロールを利用しておこなうことを以前のエントリで説明しました。これらの権限で実施できるアクセス制御の最小の単位は「表」です。ひとつの表のなかのどのデータにアクセスできるかは権限では制限できません。 Oracle...

データベースセキュリティ

[第26回] 代替コントロール

さて、このブログではデータベースセキュリティの考え方と実装方法の例を説明してきていますが、実際にお客様に提案をおこなうと、「別の方法で対策をおこなっているから」と言われることがよくあります。いわゆる代替コントロールで対応しているので提案した対策は不要と考えている訳です。 前回のエントリで例示した、ワンタイムパスワードを利用しているので共有アカウントの利用を許容することも代替コントロールの一つの例です。また、「このシステムは外部ネットワークに接続していないからサイバーセキュリティ対策は不要です」というのもネットワーク遮断という物理的な方法で代替コントロールをしようとしている例です。ちなみによくよくヒアリングしてみるとネットワークに接続していないと思っているだけのケースもあります。「ウイルス対策ソフトの定義ファイルの更新はどのようにおこなっていますか?」と聞くと「社内の更新サーバーからダウンロードしています」と答えられることもあります。社内の更新サーバーは結局外部のどこかから定義ファイルを更新しているはずであり、直接外部との接続はなくても間接的に外部と接続されている事はあります。定義ファイルの更新サーバー、データ連携サーバー、運用監視サーバーなど関連するサーバーのネットワーク構成も確認する必要があります。 また、システムが外部と完全に遮断されているために、業務のためにデータを外部に中間ファイルとしてセキュリティが十分担保されていない形で出力し、そこから情報が流出した日本の公共機関の事件や、完全にネットワークは分離していたにもかかわらず、USBデバイス経由で分離されたネットワークにウイルスが蔓延してしまった米軍のオペレーションバックショットヤンキー事件(Operation Buckshot Yankee)なども発生しているので、隔離されていれば安全というわけではありません。 代替コントロールでよく聞く対策のひとつに「アプリケーションで暗号化して、アクセス制御の代替とする」というものがあります。アプリケーションで暗号化しておけば、データベースで検索しても暗号化されたデータが戻るのでデータベース管理者からもデータが見えないため、アクセス制御はおこなう必要はないという考え方です。 たしかに検索しても平文のデータは戻りませんが、この方法では情報の破壊(削除や改ざん)には対応できません。意味のない文字列を変更され、データが破壊されても、それに気付くことも難しいです。また、データパッチなど手動でデータを修正する際には、暗号鍵を使って暗号化したデータを直接データベースに入れます。このデータパッチ処理をデータベース管理者が実施する運用をおこなっている場合にはデータベース管理者は暗号鍵を知っている事になり、暗号化していてもデータベース管理者はデータを復号できてしまいます。 暗号化しても他のアクセス制御などのセキュリティ対策も必要だという考え方が近年明文化されるようになってきました。 たとえば、個人情報は暗号化しても個人情報であり、アクセス制御などの安全管理措置(セキュリティ対策)は必要であることが、平成29年5月30日施行の改正個人情報法に関連して個人情報保護委員会や経済産業省が作成したガイドラインなどにも記載されています。 個人情報の保護に関する法律についてのガイドライン(通則編) (平成28年11月 個人情報保護委員会) P5 2-1 個人情報報 (法第2条第1項関係) 「個人に関する情報」とは、氏名、住所、性別、生年月日、顔画像等個人を識別する情報に限られず、個人の身体、財産、職種、肩書等の属性に関して、事実、判断、評価を表す全ての情報であり、評価情報、公刊物等によって公にされている情報や、映像、音声による情報も含まれ、暗号化等によって秘匿化されているかどうかを問わない。 個人情報の保護に関する法律についての経済産業分野を対象とするガイドライン (平成28年12月28日厚生労働省・経済産業省告示第2号) P2 2-1-1.「個人情報」(法第2条第1項関連) 「個人情報」とは、生存する「個人に関する情報」であって、特定の個人を識別することができるもの(他の情報と容易に照合することができ、それにより特定の個人を識別することができるものを含む。)をいう。「個人に関する情報」は、氏名、性別、生年月日等個人を識別する情報に限られず、個人の身体、財産、職種、肩書等の属性に関して、事実、判断、評価を表すすべての情報であり、評価情報、公刊物等によって公にされている情報や、映像、音声による情報も含まれ、暗号化等によって秘匿化されているかどうかを問わない(ただし、「2-2-3-2.安全管理措置(法第20条関連)」の対策の一つとして、高度な暗号化等による秘匿化を講じることは望ましい。)。 個人情報保護委員会は業種を問わず全ての事業者が個人情報を管理するうえで必要な措置を策定し、各事業者を監視・監督する機関です。このガイドラインは全ての事業者が遵守すべきものとなりますが、ここで暗号化されていても個人情報だと明記されており、暗号化はアクセス制御の代替コントロールにはならない事を示しています。また、経済産業省のガイドラインでも同等の記載があり、さらに暗号化はやっておいた方が望ましい、つまり経済産業省は暗号化もアクセス制御も  おこなう必要があるとしています。 代替コントロールを実施するときに注意すべき点は、もともとの対策で軽減できるリスクのすべてを、代替コントロールで十分に対応できているかどうかです。個人アカウントの利用という対策の代替コントロールとして、ワンタイムパスワードを利用する場合、匿名性は排除できますが、個人アカウント利用を前提とした最小権限の原則は実現できないため、共有アカウントを利用していても最小権限の原則を実現するための対策を考慮する必要があります。代替コントロールを選択することで、もともとの対策以上のコストがかかってしまったり、システムが複雑になってしまったりすることもありますので注意が必要です。 代替コントロールに関してはクレジットカード番号情報保護のためのガイドラインであるPCI-DSSでも安易に利用しないように注意がされています。「PCI-DSS 代替コントロール」で検索するとさまざまな専門家が書いた情報にアクセスできますのでこちらもご参照ください。 このブログで記載しているセキュリティ対策(一部私見もありますが、ベースはOracle Databaseのセキュリティ対策のベストプラクティスです)や個人情報保護法のガイドラインなどに記載されている「望まれる手法の例示」で記載されているセキュリティ対策は、リスクに対応するための唯一の方法ではありません。しかし、全体としてセキュリティを担保するための有効な方法として識者が導き出した対策であり、システムの規模や環境に依存してしまうところもありますが、一般的にはもっともリーズナブルなものです。一見大変そうな対策も書かれていますが、安易に代替コントロールの利用に逃げずに、セキュリティ対策をおこなっていただきたいと考えています。 「もくじ」にもどる

さて、このブログではデータベースセキュリティの考え方と実装方法の例を説明してきていますが、実際にお客様に提案をおこなうと、「別の方法で対策をおこなっているから」と言われることがよくあります。いわゆる代替コントロールで対応しているので提案した対策は不要と考えている訳です。 前回のエントリで例示した、ワンタイム...

ID管理・認証

[第25回] 個人アカウントと匿名性の排除 ~ ワンタイムパスワード

さて、今までのエントリで散々個人アカウントを利用しましょう、と説明してきました。 個人アカウントの利用を推奨するのは、匿名性を排除するためです。利用者の特定はアクセス制御や監査を実施するうえでの前提条件となります。 ただし、匿名性を排除できるのであれば、必ずしもデータベースにアクセスする際に個人アカウントを利用しなければいけないわけではありません。個人アカウントの利用は匿名性の排除の手段のひとつですが、必ずしも唯一の方法ではありません。 たとえばデータベース上の共有カウント利用時にワンタイムパスワードを利用する方法があります。ワンタイムパスワードを発行した人が誰かが特定できれば、データベース上の共有アカウントを利用したのが誰か特定できることになり、匿名性が排除された状態は保たれます。 ただし、注意が必要なのはこれは個人の特定はデータベース側でなくワンタイムパスワード発行システム側でおこなうという、ワンタイムパスワード管理システムへのリスクの転移です。匿名性の排除のために個人アカウントの利用の代わりに、ワンタイムパスワードという代替コントロールをおこなっていることになります。 データベース側ではワンタイムパスワード管理システムがセキュリティが確保された状態で正常に動作し、そこで個人が識別できるという前提でデータベースでは匿名性がない状態を許容しています。ワンタイムパスワード管理システムの管理者であれば、自由にワンタイムパスワードを発行できることになります。  さらにワンタイムパスワードの利用で担保できているのは個人の特定のみであり、最小権限の原則の実現は別に考える必要があります。SYSやSYSTEMのデータベース管理アカウントにワンタイムパスワードを利用して個人が特定できるようにしている場合でも、その管理アカウントの利用者が必ずしもデータベースに対して全ての操作をおこなってよいわけではありません。たとえばデータベースのバックアップ運用をおこなっている担当者は個人情報やクレジットカード情報などアプリケーションのデータを参照する権限があってはいけないこともあります。また、管理者権限でワンタイムパスワードをバイパスするユーザーを作成したり、別のユーザーに必要以上の権限を付与したりしてしまうかもしれません。ワンタイムパスワードを利用して匿名性を排除しているからといって、SYSやSYSTEMなどのデータベース管理者アカウントを利用する運用が常に安全とはいえません。 また、監査に関しても複数のシステムのログを突き合わせる必要があり、管理は複雑になります。 データベースを管理していくうえでどうしてもSYSやSYSTEMなどの管理権限が必要になり、これらのアカウントを利用しなければならないときにワンタイムパスワードは個人を特定するうえでのひとつの有効なソリューションです。ただし、ワンタイムパスワードを利用しデータベースの特権ユーザーを利用を許可することで、すべてのセキュリティ上の課題を解決するわけではないので注意が必要です。 「もくじ」にもどる  

さて、今までのエントリで散々個人アカウントを利用しましょう、と説明してきました。 個人アカウントの利用を推奨するのは、匿名性を排除するためです。利用者の特定はアクセス制御や監査を実施するうえでの前提条件となります。ただ...

ID管理・認証

[第24回] パスワードプロファイルの作り方の例

データベースのアカウントの分類方法はいくつもありますが、どのように利用されることを目的として作成されたかという観点からだと下記の3つに分類できます。   アプリケーション用のユーザー(人間が使わないアカウント) 直接データベースにログインして利用するユーザー(人間が利用するアカウント) デフォルトで最初から作成されているユーザー(運用フェーズでは誰も利用すべきでなないアカウント) 今回はそれぞれの種類のアカウントにどのようなパスワードプロファイルを適用すべきかを説明します。もちろん、これが唯一無二の方法ではありませんが、セキュリティを担保するためのパスワードプロファイルの作り方の考え方のひとつとして参考にしていただければと思います。 まず、デフォルトで最初から作成されているユーザーには、デフォルトでDEFAULTというユーザープロファイルが適用されています。Oracle Database 11g以降ではデフォルトのパスワードプロファイルが変更されています。もっとも影響のある点はパスワードの有効期限(PASSWORD_LIFE_TIME)が180日に設定されている事だと考えます。つまり、データベース初期状態では6ヶ月後にパスワード変更をアナウンスされ、さらに猶予期間(PASSWORD_GRACE_TIME)の7日間を過ぎるとアカウントが期限切れ(EXPIRED)の状態となり、ログイン時にパスワード変更プロンプトが表示されることにより、アプリケーションからデータベースにログインできない状態になってしまいます。 さまざまなシステムに対してアセスメントを実施していますが、多くのシステムでは導入時にDEFAULTのパスワードプロファイルを変更して、有効期限を無制限にしていました。有効期限を無期限にすることでセキュリティレベルは落ちますが、実運用を考えるとセキュリティリスクが落ちるリスクを受け入れてでもこの変更をおこなう事は仕方がないことかもしれません。ただし、パスワードの有効期限を無期限にするのであれば、簡単に推測できるパスワードを利用しないようにすべきです。複雑なパスワードを強制するために複雑度検証ファンクション(PASSWORD_VERIFY_FUNCTION)の利用も考慮して下さい。 DEFAULTのパスワードプロファイルに対する変更として、失敗許容回数(FAILED_LOGIN_ATTEMPTS)も無制限にしているシステムもありました。ただし、失敗許容回数を無制限にしていると、パスワード推測攻撃を防ぐ事ができませんので、この設定は変更しないべきと考えます。また、攻撃に気付くためにもログイン失敗の監査を取得し、定期的に確認することを推奨します。 デフォルトで最初から作成されているユーザーはパスワードを強固なものにして守る運用よりも、SYS、SYSTEMといったデータベース管理者を含めて、基本的には運用中は利用せず個人アカウントを利用するという匿名性を排除する運用を優先すべきです。  次に、アプリケーション用のユーザーですが、人間が利用しないプログラムが利用するユーザー用のプロファイルを最低ひとつは作成すべきです。この種類のデータベースユーザーのパスワードは変更する際の影響が多いため、パスワード有効期限を無期限にすることが多いです。またアカウントがロックされてしまうとアプリケーションの動作に影響するため、失敗許容回数も無制限にすることが多いです。ただし、失敗許容回数を無制限にしていると、パスワード推測攻撃を防ぐ事ができませんので、この設定は変更しないべきと考えます。また、攻撃に気付くためにもログイン失敗の監査を取得し、定期的に確認することを推奨します。 また、複雑なパスワードを強制するために複雑度検証ファンクション(PASSWORD_VERIFY_FUNCTION)を利用して下さい。 万が一パスワードが漏えいしてしまった時にパスワードを変更できるようにユーザーのパスワードがどこに設定されているかもきちんと把握しておくことも重要です。 最後は、直接データベースにログインして利用するユーザーです。人間が利用するユーザー用のプロファイルを最低ひとつは作成すべきです。 以前のエントリでも説明しましたが、頻繁なパスワード変更の強制は利用者が複雑なパスワードを思いつかない、覚えられない等の理由で逆に簡単なパスワードや推測されやすいパスワードを設定してしまう可能性がありますので、パスワードの定期的な変更の強制はおこなうとしても頻度は高すぎないようにすべきです。ガイドラインや社内ポリシーなどでパスワードの定期的な変更が必須ではない場合には、アカウントのパスワードは容易に想像できない複雑で、本人以外は知らない状態に保たれている場合には、パスワードの有効期限を設定しないという運用方法も考えられます。もし社内にID管理の仕組みがあれば、その仕組みと連携して、メールや他の社内システムのパスワードとデータベースユーザーのパスワードを同期するとさらに安全に管理できます。 人間が利用するアカウントではパスワード失敗回数によるアカウントロックや複雑度検証ファンクションは有効化しておくべきです。ただし、頻繁なパスワード変更を強制するとパスワードを忘れ、頻繁にロックされてしまい業務に影響がでたり、データベース管理者の運用の手間が増えたりすることも想定できるので注意が必要です。 このブログではユーザーを3種類に分けてそれぞれどのように作成していくべきかを説明していますが、パスワードプロファイルでもこの3種類それぞれに適切にポリシーを設定していくことを推奨します。データベース作成後に手動で作成したユーザーにはそれぞれ適切なプロファイルを設定することで、運用中に不適切なプロファイルが適用されていないか確認することも簡単になります。すべてのユーザーに同一のデフォルトプロファイルを適用するのではなく、適切にプロファイルを作成し、安全なパスワード管理を実施して下さい。 「もくじ」にもどる

データベースのアカウントの分類方法はいくつもありますが、どのように利用されることを目的として作成されたかという観点からだと下記の3つに分類できます。   アプリケーション用のユーザー(人間が使わないアカウント) 直接データベースにログインして利用するユーザー(人間が利用するアカウント) デフォルトで最初から作成されているユーザー(運用フェーズでは誰も利用すべきでなないアカウント) 今回はそれぞれの種類のアカ...

データベースセキュリティ

【事例】 楽天証券様 DBセキュリティ事例

楽天証券様のマイナンバー情報を格納する顧客情報管理システムへのデータベースセキュリティ製品を用いた多層防御のアプローチで短期構築を実現頂いた事例が公開されました。楽天証券は多層防御でマイナンバーを安全管理 オラクルのデータベースセキュリティ製品はどう使われたのか? ー DBアクセス制御、暗号化、監査で高セキュアな個人情報管理を実現 データベースセキュリティ製品としては、以下を採用頂きました。 職務分掌によるきめ細かなデータベースアクセス制御を可能にする「Oracle Database Vault」 極めて少ないオーバーヘッドによるデータベース暗号化を実現する「Transparent Data Encryption」(Oracle Advanced Securityの一機能) 監査・監視を行う「Oracle Audit Vault and Database Firewall」 また、データベース基盤には「Oracle Database Appliance」が採用頂きました。 (ご参考) 楽天証券、マイナンバー対応のセキュリティ対策をオラクル製品・サービスの活用により実現 [プレスリリース] お時間ある時にご一読下さい。

楽天証券様のマイナンバー情報を格納する顧客情報管理システムへのデータベースセキュリティ製品を用いた多層防御のアプローチで短期構築を実現頂いた事例が公開されました。 楽天証券は多層防御でマイナンバーを安全管理 オラクルのデータベースセキュリティ製品はどう使われたのか? ー DBアクセス制御、暗号化、監査で高セキュアな個人情報管理を実現 データベースセキュリティ製品としては、以下を採用頂きました。 職務分掌...

ID管理・認証

[第23回] パッケージアプリケーションのユーザー

データベースのアカウントの分類方法はいくつもありますが、どのように利用されることを目的として作成されたかという観点からだと下記の3つに分類できます。   アプリケーション用のユーザー(人間が使わないアカウント) 直接データベースにログインして利用するユーザー(人間が利用するアカウント) デフォルトで最初から作成されているユーザー(運用フェーズでは誰も利用すべきでなないアカウント) この3つのユーザーをどのように作成し、管理すべきかは以前のエントリで説明しました。アプリケーション用のユーザーについてもどのように作成し、管理していくべきかも説明しましたが、アプリケーション用のユーザーを常に自分で設計できるわけではありません。それは、パッケージアプリケーションを利用している場合です。パッケージアプリケーションを利用している場合、アプリケーション用のユーザーは自動的に作成され、権限設定をカスタマイズできないことが多いです。 パッケージアプリケーションではデータベースユーザーをひとつだけ作成し、表を作成し、アプリケーションからデータにアクセスする際にも同じユーザーを利用するものも多いです。多く利用されているパッケージアプリケーションの場合、作成されるデータベースユーザー名が広く知られていますので、そのユーザー名でログイン試行するような攻撃が考えられます。作成するユーザーのパスワードを推測できない複雑なものにし厳密に管理することが重要です。また、そもそもこのような攻撃を受けないためにもデータベースサーバーへのアクセス経路を制限することも重要です。アクセス経路の制限に関しては以前のエントリにも記載していますのでそちらもご参照ください。 アクセス経路の制限が十分にできない場合には、想定のアクセス経路以外からアクセスの監査ログの設定をおこない、システムの重要度に応じて即時のアラートや定期的なレポーティングで想定外アクセスに気付ける仕組みの作成を考慮してください。 権限管理の観点からは、パッケージアプリケーションといえど、付与されている権限は確認するようにしましょう。とくに他のデータベースユーザーのオブジェクトを操作できるANYシステム権限(とそれを含むDBAやEXP_FULL_DATABASEなどのロール)には注意が必要です。そのデータベースをパッケージアプリケーションだけで利用している場合は問題は顕在化しませんが、他のシステムとデータベースを共用したり、データベース統合をおこなおうとした際に他のシステムのデータにアクセスできてしまいます。 パッケージアプリケーションで付与されている権限を変更することは難しいため、必要であればDatabase Vaultを利用して権限が付与されていてもデータにはアクセスできなくするなどの対策をとってください。 通常パッケージアプリケーションでは内部動作が公開されていないため、データベース側で監査をとることが難しいです。パッケージアプリケーションでの操作の監査はパッケージアプリケーションの機能を利用して実施し、データベース側ではパッケージアプリケーション経由のアクセスは監査をとらず、想定されたアクセス経路(アプリケーションからのアクセス)以外のアクセスログをデータベース監査で取得するように設計してください。 パッケージアプリケーションのユーザーは自動的に(勝手に?)作成・権限付与されるため、あまり注意が払われないところかもしれませんが、ユーザー名が固定であることも多く、攻撃者から狙われやすい個所でもあります。実施できる対策も制限されてしまうところもありますが、重要なデータを格納していることも多いのでできるところから着手してください。 「もくじ」にもどる

データベースのアカウントの分類方法はいくつもありますが、どのように利用されることを目的として作成されたかという観点からだと下記の3つに分類できます。   アプリケーション用のユーザー(人間が使わないアカウント) 直接データベースにログインして利用するユーザー(人間が利用するアカウント) デフォルトで最初から作成されているユーザー(運用フェーズでは誰も利用すべきでなないアカウント) この3つのユーザーをどのよ...

アクセス制御

[第22回] PUBLICに注意

Oracle DatabaseにはPUBLICという特別なロールがあります。ちなみに11g以降のマニュアルにはPUBLICロールと記載されていますが、10g以前ではPUBLICユーザー・グループと表記されており、DBA_ROLESにはリストされず、DBA_USERSにリストされているため、純粋なロールと言い切れないところが特別なロールと記載した理由です。DBA_USERSにリストされるので最新のマニュアルなどの資料でもユーザーと表記されている個所もあります。 このブログでも実はカテゴリ分類をおこなっていて、「ID管理・認証」というカテゴリと「アクセス制御」というカテゴリがあります。PUBLICがユーザーの場合は「ID管理・認証」に分類されますが、ロールの場合は「アクセス制御」に分類されます。ここではPUBLICはロールという事にして「アクセス制御」に分類します。まぁ、どうでもよい話ですが。 このPUBLICロールにシステム権限やオブジェクト権限を付与した場合、その権限はすべてのデータベースユーザーが利用可能になりますので注意が必要です。マスター表など他のユーザーにも見せたい表へのアクセス権限を面倒だからといってPUBLICロールに付与してしまっているシステムを見かけますが、他のシステムのデータも同じデータベースに格納されるようになったり、データベース統合をおこなったりすると、関係ない人からも見えてしまいますので注意が必要です。最小権限の原則の実現のためにも、PUBLICロールには追加で権限を付与しないようにしましょう。 また、デフォルトでPUBLICロールに付与されている権限にも注意が必要です。 このロールには下位互換のために必要以上に強力な権限が付与されています。 たとえば、Database Vaultを有効にすると、PUBLICロールからはUTL_FILEパッケージプロシージャへのEXECUTE権限が取り消されます。UTL_FILEパッケージプロシージャは外部OSファイルに入出力ができるようになるため、データベースの情報が外部ファイルに書き出される危険性を最小化するためです。この動作はマニュアルにも記載されています。 そのほかにもUTL_TCP、UTL_HTTP、UTL_SMTPといった様々なプロトコルで外部と通信するためのパッケージプロシージャもPUBLICに付与されていますので、データベースサーバーに対するインバウンドの通信を制限するだけでなく、アウトバウンドの通信の適切に制限しておくべきです。 PUBLICロールは昔からある機能で、古いシステムで利便性のために利用されたままになっていることもあります。PUBLICロールの気軽な利用は情報漏洩のリスクにもなり、またデータベース統合の妨げにもなります。新しく作成するシステムではPUBLICロールに権限を追加しないようにし、既存のデータベースでもPUBLICロールにアプリケーションデータへのアクセス権限やカスタムプログラムの実行権限が付与されていないかどうか棚卸してみてください。  「もくじ」にもどる

Oracle DatabaseにはPUBLICという特別なロールがあります。ちなみに11g以降のマニュアルにはPUBLICロールと記載されていますが、10g以前ではPUBLICユーザー・グループと表記されており、DBA_ROLESにはリストされず、DBA_USERSにリストされているため、純粋なロールと言い切れないところが特別なロールと記載した理由です。DBA_USERSにリストされるので最新のマニ...

データベースセキュリティ

【資料公開】 Oracle Cloud Day 2016 / DBA & Developer Day 2016 セキュリティセッション

2016年10月25日-26日開催の Oracle Cloud Days 2016 および、2016年10月27日開催の Oracle DBA & Developer Day 2016に多くの方にご参加頂きありがとうございます。 以下からダウンロード可能になりました。ご興味のある方是非ご確認下さい。 Oracle Cloud Days 2016 [D2-K1]3年間の情報漏洩事件を振り返り、今考える、必須のセキュリティ対策の勘所~ 事例やガイドラインからみるデータ保護に求められる施策とは &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;span id=&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;XinhaEditingPostion&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/span&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt; [D2-K2]米国での取組を解説、データ中心の縦深(多層)防御とサイバーレジリエンスの考え方~ 不測な事態への早期の復旧・回復に求められる取り組みとは ~ その他のセッション資料は、こちらからダウンロードできます。  『Oracle Cloud  Day 2016』のセッション資料 Oracle DBA & Developer Days 2016 [DD4-1]これだけは押さえたい! 現場で使えるデータベース・セキュリティ~明日セキュリティ設計を任されるかも知れないあなたへ~  [DD3-5]Oracle Database 12c : セキュリティ新機能でデータベースをより強固に守る その他のセッション資料は、こちらからダウンロードできます。 『Oracle DBA & Developer Day 2016』のセッション資料

2016年10月25日-26日開催の Oracle Cloud Days 2016 および、 2016年10月27日開催の Oracle DBA & Developer Day 2016に多くの方にご参加頂きありがとうございます。 以下からダウンロード可能になりました。ご興味のある方是非ご確認下さい。 Oracle Cloud Days 2016 [D2-K1]3年間の情報...

ID管理・認証

[第21回] デフォルトで最初から作成されているユーザー

データベースのアカウントの分類方法はいくつもありますが、どのように利用されることを目的として作成されたかという観点からだと下記の3つに分類できます。   アプリケーション用のユーザー(人間が使わないアカウント) 直接データベースにログインして利用するユーザー(人間が利用するアカウント) デフォルトで最初から作成されているユーザー(運用フェーズでは誰も利用すべきでなないアカウント)   今回はデフォルトで最初から作成されているユーザーの考え方を説明します。もちろん、これが唯一無二の方法ではありませんが、セキュリティを担保するためのデータベースユーザー利用の考え方のひとつとして参考にしていただければと思います。 Oracle Databaseではデータベース作成時に既に複数のデータベースユーザーが作成されています。たとえばSYS、SYSTEMといったデータベース管理用アカウントやDBSNMP、OUTLNといった各種データベース機能が利用するアカウントやサンプルスキーマです。 これらのアカウントは可能な限りロックして、運用中は基本的には直接データベースに接続するユーザーとして利用しないべきです。特に事前作成されたアカウントにさらに権限を付与して利用することは危険です。 事前定義のアカウントは攻撃者にとってみれば、必ず存在する、もしくは存在する可能性が高いアカウントです。アカウントの奪取を試みるときにまずはこれらのアカウントが狙われやすいです。特にSYSやSYSTEMは強い権限を持っていて必ず存在するアカウントですので、最初に狙われることが多いです。これらのアカウントは容易に想像できない複雑なパスワードを設定し、だれからも利用されないようにして、ログイン試行があった場合には必ず監査し、必要であれば攻撃検知のアラートが上がるようにしておいた方がよいでしょう。 これらのアカウントを利用するのは、データベースが壊れたなどの非常時のみにして、普段は適切な権限を付与した個人アカウントを利用し、これらのアカウントでのログイン試行があったら不正アクセスを疑えるようにしておくことが、内部犯行、外部攻撃を直ぐに察知し、被害を未然に防ぐことにつながります。 「もくじ」にもどる

データベースのアカウントの分類方法はいくつもありますが、どのように利用されることを目的として作成されたかという観点からだと下記の3つに分類できます。   アプリケーション用のユーザー(人間が使わないアカウント) 直接データベースにログインして利用するユーザー(人間が利用するアカウント) デフォルトで最初から作成されているユーザー(運用フェーズでは誰も利用すべきでなないアカウント)   今回はデフォルトで最初か...

データベースセキュリティ

[第20回] セキュリティ対策はどこまでやればよいのか?

セキュリティ対策のゴールはリスクをゼロにすることではありません。 リスクを受容できるレベルまで軽減することがセキュリティ対策のゴールです。 ちなみにリスクを受容できるまで軽減する以外にもリスクに対応する方法があります。 それは回避と転移です。 リスクの回避とはそもそもリスクが発生する可能性を取り去ることです。たとえば個人情報の漏洩のリスクに対して、個人情報を持たないという選択をすることです。個人情報を持つことでさらなるサービスを提供し利益を得ることができるかもしれませんが、リスクが発生する可能性が高く、また被害が大きい場合には個人情報を持たずサービスを提供しないという回避も有効です。 リスクの転移とはリスクを別の場所に移すことです。たとえばクレジットカード情報の漏洩のリスクに対して、決済サービスを他社に委託したり、保険をかけて被害を受けても金銭的な影響を少なくすることです。リスクによる被害が大きい場合にはリスクを転移することも有効です。 そもそも絶対に安全はありえません。受容できるレベルのリスクをさらに軽減する必要はありません。対策のしすぎというやつです。 では、どのレベルのリスクであれば受容できるとしてよいのでしょうか? セキュリティ対策はどこまでやればよいのか、というのは決まった答えのない非常に難しい問題です。 ここでは、どこまで対策をすべきか考えるための3つの観点を紹介したいと思います。 ひとつめは、データの価値、そのデータはどれだけ重要か、という事です。 重要なデータであればあるほどきちんと守るべきです。そのデータが漏洩した時の影響を考えてください。 被害の範囲、漏洩ルート、原因の究明、対外的な説明、今後の対策、損害賠償(お詫び?)。さまざまな費用が発生します。自社のリソースだけで対応できない場合、外部のコンサルタントに依頼する必要があるかもしれません。自分や上長、会社の役員の処分、減俸、引責辞任、運用を担当していた情報子会社の解体、顧客離れなど今後のサービス提供への影響などもあるかもしれません。 事件が発生してしまった後には結局おこなわなくてはならない「今後の対策」を事前にやっておけばという後悔をしないためにも、重要なデータが入っている場合にはきちんと対策をおこなうべきだと責任を取らされそうな上司に上申すべきです。事件発生時に自分が責任を取らなきゃいけない事も含めて影響を理解してそれでも対策をおこなわないのは、リスクを受容(放置と言いたいですが)していることになります。 ふたつめは、各種法令やそれに伴うガイドラインです。 ガイドラインはどんどん更新されています。なぜ更新されているかというと、事件が発生しているからです。ガイドラインには実際に発生した事件を受けて、そのような事件が再発することがないようにどのような対策をすべきかが記載されています。ガイドラインには厳しい事が記載されていると感じるかもしれませんが、その対策をおこなっていなかったから事件は発生したのであり、個人情報、クレジットカード番号情報など重要な情報に対してはガイドラインに書かれている対策をとるべきです。 さて、企業理念や経営計画、行動規範、行動基準をホームページで広く公開している企業も多いです。そこに法令遵守などコンプライアンス対応が明記されていることも多いです。企業として対応を謳っている場合、対策しなくてはいけないと知っていて対応していないと、万が一事件が発生してしまったときに、説明責任を果たすことができなくなってしまいます。セキュリティ対策はどうしてもコストと見られてしまうため、対策の必要性と対策しなかったときの影響はきちんと上司や責任者に報告するべきです。 さいごは業界標準、他の会社はどこまでやっているかです。 とはいえ、監査が入る業種を除いてはデータベースのセキュリティ対策まで手が回っている会社は残念ながら多くはありません。だからといって全く考慮しなくてよいわけではありません。先日のデータベースへのランサムウェア攻撃もそうでしたが、まず狙われるのは対策ができていない脆弱なシステムです。このブログでは有償オプションでない基本機能でおこなえる対策も多く紹介しています。適切な対策をおこない攻撃者からデータをとるのは難しいなと諦められるシステムを作っていただきたいです。 「もくじ」にもどる

セキュリティ対策のゴールはリスクをゼロにすることではありません。 リスクを受容できるレベルまで軽減することがセキュリティ対策のゴールです。 ちなみにリスクを受容できるまで軽減する以外にもリスクに対応する方法があります。 それは回避と転移です。 リスクの回避とはそもそもリスクが発生する可能性を取り去ることです。たとえば個人情報の漏洩のリスクに対して、個人情報を持たないという選択をすることです。個人情報...

データベースセキュリティ

【2/21開催】 セキュリティ・フォーラム 2017 [改正個人情報保護法のポイントとサイバー脅威の正しい怖がり方と考え方を解説]

2月21日(火)に「オラクル・セキュリティ・フォーラム 2017 ~ 新しい個人情報保護法とサイバー攻撃の動向からみる「攻め」と「守り」のセキュリティ対策」と題した、セミナーを開催します。 最近お問い合わせが多い個人情報保護法の改正のポイントや、最新のサイバー攻撃の動向とサイバー脅威の正しい怖がり方と考え方を中心にご紹介します。 ご都合つく方は、是非ご参加頂けますようお願いします。 本セミナーのポイントは、以下となります。 改正個人情報保護法のポイント、データ利活用・保護に与える影響について EU GDPR等の海外の動向とインパクト IPAにも所属する佳山様による「サイバー脅威の正しい怖がり方と考え方」の解説 - 標的型攻撃のリアルデモの実演あり 情報漏洩事件やアセスメント結果からみるデータ保護対策の勘所   - データベースへのアセスメント実施結果から顧客の現状と今取り組むべきポイントを紹介   申込サイトは、以下となります https://www.oracle.com/goto/jpm170221sec     日時: 2017年2月21日(火) 14:00~17:00(受付時間 13:30~) 会場: 赤坂センタービルディング 東京都港区元赤坂1-3-13 主催: 日本オラクル株式会社 協賛: 富士通株式会社 参加費: 無料 対象: ・ セキュリティ管理者・担当者 ・ システム管理者・担当者 ・ 情報システム部門、経営企画部門の方   ■ご同業者の方のご参加はお断りさせて頂く場合がございます。 ■お申込多数の場合は、上記対象者の方を優先させていただく場合がございます。 定員: 50 名 お問い合わせ: 日本オラクル株式会社 「セキュリティ・フォーラム 2017」事務局 E-mail: orasol_jp@oracle.com 申込サイト: https://www.oracle.com/goto/jpm170221sec           「もくじ」にもどる

2月21日(火)に「オラクル・セキュリティ・フォーラム 2017 ~ 新しい個人情報保護法とサイバー攻撃の動向からみる「攻め」と「守り」のセキュリティ対策」と題した、セミナーを開催します。 最近お問い合わせが多い個人情報保護法の改正のポイントや、最新のサイバー攻撃の動向とサイバー脅威の正しい怖がり方と考え方を中心にご紹介します。 ご都合つく方は、是非ご参加頂けますようお願いします。 本セミナーのポイ...

ID管理・認証

[第19回] 直接データベースにログインするために利用するユーザー

データベースのアカウントの分類方法はいくつもありますが、どのように利用されることを目的として作成されたかという観点からだと下記の3つに分類できます。   アプリケーション用のユーザー(人間が使わないアカウント) 直接データベースにログインして利用するユーザー(人間が利用するアカウント)  デフォルトで最初から作成されているユーザー(運用フェーズでは誰も利用すべきでなないアカウント) 今回は直接データベースにログインして利用するユーザーの作り方の考え方を説明します。もちろん、これが唯一無二の方法ではありませんが、セキュリティを担保するためのデータベースユーザー作成の考え方のひとつとして参考にしていただければと思います。 今回説明する直接データベースにログインして利用するユーザーには、たとえばデータベースの管理や運用をおこなう担当者やアプリケーションデータのメンテナンスをおこなう担当者、データ分析やクライアントサーバー形式のアプリケーションを利用するためにデータベースに直接アクセスするエンドユーザーがいます。 まず重要なのがアカウントを複数の人で共有せず、個人用のアカウントの利用を基本とする事です。データベースに直接アクセスする必要がある人には、臨時でデータベースにアクセスするベンダーなどの作業員を含めて全て誰がその操作をおこなったかを確実に特定できるようにしてください。臨時作業などで利用するためのアカウントは複数の人が利用する可能性はありますが、利用ごとにパスワードを変更するなど、同時に複数の人がアクセスできる状態にしないなどの工夫をして匿名性を排除して下さい。 アクセス制御で最小権限の原則を実現したり、監査を実施した際に監査証跡から実際に操作した人を特定するうえでも匿名性の排除は重要です。 各省庁が出している個人情報保護に関するガイドラインや政府機関等の情報セキュリティ対策のための統一基準などでも、個人の識別に言及されています。これらの基準を守る上でも個人用のアカウントの利用は重要です。 (個人情報の保護に関する法律の改正に伴い、個人情報保護に関するガイドラインもより厳格な方向に更新されていきますので、新しく出てくる個人情報保護に関するガイドラインにも注意が必要です) 作成したアカウントのパスワードは容易に想像できない複雑なものにして、本人以外は知らない状態に保つことが重要です。 パスワードの定期的な変更の強制も効果的ですが、頻繁なパスワード変更の強制は利用者が複雑なパスワードを思いつかない、覚えられない等の理由で逆に簡単なパスワードや推測されやすいパスワードを設定してしまう可能性がありますので、注意が必要です。ガイドラインなどではパスワードの定期的な変更を求めているものも多いですが、パスワードは定期的に変更しないほうが安全という意見もあります。詳しくは「パスワード 定期的 変更」などで検索してみてください。ただし、どちらにせよ設定するパスワードは推測できない複雑なものにして、パスワードが外部に漏れた可能性がある場合にはただちに変更しなくてはならないのには変わりはありません。 アプリケーションデータのメンテナンスをおこなう担当者のアカウント、およびデータ分析やアプリケーションを利用するためにデータベースに直接アクセスするエンドユーザー用のアカウントに付与するアクセス権限はアプリケーション用のアカウントと基本的に同じ考え方ができます。データベースに接続するためにCREATE SESSIONシステム権限と、必要な表へのオブジェクト権限(をまとめたロール)以外を付与する場合には、その権限が本当に必要かどうか、その権限を付与することで不要な操作がされる可能性はないかどうかを確認するようにしてください。SQL*Plusなどのツールを利用して自由にSQL文を発行できますので権限の付与には注意が必要です。たとえば表を作成するためのCREATE TABLEシステム権限が付与されていた場合、自分で新しい表を作成し、そこに他の表からデータをロードし、作成した表へのSELECT権限をPUBLICに付与するという一連の操作で、本来権限のない人でもデータにアクセスできるような状態としてしまう事ができます(WRITE DOWNとも呼びます)。 データベースの管理や運用をおこなう担当者用のアカウントに付与するアクセス権限で注意が必要なのがその人がデータにアクセスする必要があるかどうかという事です。データベースの運用を業務部門ではなくIT部門がおこなっていたり、外部の業者に委託している場合、その人たちはアプリケーションのデータを見る必要はないはずです。このような人たちにデータにアクセスする権限を与えることは最小権限の原則からはずれてしまいます。最小権限の原則を実現するためには、このような用途のアカウントには、表へのオブジェクト権限だけでなく、データにアクセスできるSELECT ANY TABLEなどのANY権限とそれを含むロール(DBA、EXP_FULL_DATABASEなど)に付与もおこなわないようにすべきです。 面倒にも感じますが、個人情報保護のガイドラインや政府機関等の情報セキュリティ対策のための統一基準などにも記載されている「管理者権限の分割」や「管理者アカウントの適正な権限管理」をおこなうためには必要なことです。 データベースに直接アクセスする利用者はSQL文を自由に発行できるという点だけでも、通常のアプリケーションから定形処理しかおこなわない利用者と比べると、特権ユーザー、パワーユーザーとなります。このようなアカウントを利用した不正や事故がおこらないように最小権限の原則を徹底させてください。 なお、SELECT ANY TABLEシステム権限やそれを含むロール(DBAなど)を付与していても実際のデータにアクセスできないようにするためにOracle Database Vaultが利用できます。この有償オプションを導入いただくことで既存のDBAロールなどを利用したアクセス設計を継承しつつ、管理者であってもアプリケーションデータにはアクセスできない環境を実現できます。ぜひご検討ください。 「もくじ」にもどる

データベースのアカウントの分類方法はいくつもありますが、どのように利用されることを目的として作成されたかという観点からだと下記の3つに分類できます。   アプリケーション用のユーザー(人間が使わないアカウント) 直接データベースにログインして利用するユーザー(人間が利用するアカウント)  デフォルトで最初から作成されているユーザー(運用フェーズでは誰も利用すべきでなないアカウント) 今回は直接データベースに...

アクセス制御

[第18回] エクスポート/インポートで利用する権限の注意点

Oracle Databaseでは論理バックアップを取得するためにエクスポート/インポートの仕組みを提供しています。 ユーザーが自分のスキーマのオブジェクトをエクスポートする際にはダンプファイルを出力するディレクトリへの書込み権限以外データにアクセスする権限を特に追加する必要はありませんが、他スキーマのオブジェクトを含めてエクスポートを実行する際に、EXP_FULL_DATABASEロールを付与することがあると思います。 実はこのEXP_FULL_DATABASEロールには強力な権限が付与されているため注意が必要です。 SQL> select privilege from dba_sys_privs where grantee='EXP_FULL_DATABASE'; PRIVILEGE ---------------------------------------- CREATE TABLE RESUMABLE EXECUTE ANY PROCEDURE EXEMPT REDACTION POLICY ADMINISTER SQL MANAGEMENT OBJECT BACKUP ANY TABLE READ ANY FILE GROUP ADMINISTER RESOURCE MANAGER EXECUTE ANY TYPE SELECT ANY SEQUENCE SELECT ANY TABLE CREATE SESSION 12行が選択されました。 全てのユーザーの表を参照できるSELECT ANY TABLEシステム権限に加えて、全てのユーザーのストアドプロシージャを実行できるEXECUTE ANY PROCEDURE、さらにはData RedactionのセキュリティポリシーをバイパスできるEXEMPT REDACTION POLICYが付与されます。 同様にIMP_FULL_DATABASEにも、さらに強力な権限が付与されています。 SQL> select privilege from dba_sys_privs where grantee='IMP_FULL_DATABASE'; PRIVILEGE ---------------------------------------- GRANT ANY OBJECT PRIVILEGE DROP ANY DIMENSION CREATE ANY LIBRARY DROP ANY DIRECTORY DROP ANY MATERIALIZED VIEW DROP PROFILE DROP ANY PROCEDURE DROP PUBLIC DATABASE LINK DROP ANY CLUSTER ALTER ANY TABLE AUDIT SYSTEM RESUMABLE GLOBAL QUERY REWRITE ALTER ANY TYPE ALTER PROFILE EXECUTE ANY PROCEDURE CREATE ANY CLUSTER DROP ROLLBACK SEGMENT BECOME USER DROP TABLESPACE DROP ANY OPERATOR CREATE ANY OPERATOR ANALYZE ANY ALTER ANY PROCEDURE CREATE ANY SEQUENCE COMMENT ANY TABLE ADMINISTER SQL MANAGEMENT OBJECT CREATE ANY SQL PROFILE DROP ANY SQL PROFILE ALTER ANY TRIGGER AUDIT ANY CREATE ROLE DROP ANY SYNONYM DROP ANY INDEX ALTER USER MANAGE ANY QUEUE EXECUTE ANY OPERATOR DROP ANY TRIGGER DROP ANY SEQUENCE DELETE ANY TABLE UPDATE ANY TABLE INSERT ANY TABLE DROP ANY TABLE CREATE ANY TABLE ADMINISTER RESOURCE MANAGER CREATE ANY DIMENSION DROP ANY INDEXTYPE DROP ANY LIBRARY EXECUTE ANY TYPE DROP ANY TYPE CREATE ANY DIRECTORY GRANT ANY PRIVILEGE ALTER RESOURCE COST CREATE PROFILE CREATE ANY PROCEDURE CREATE ANY SYNONYM CREATE ROLLBACK SEGMENT CREATE TABLESPACE DROP ANY CONTEXT CREATE ANY TYPE CREATE ANY TRIGGER ALTER DATABASE CREATE PUBLIC SYNONYM CREATE ANY INDEX SELECT ANY TABLE CREATE USER CREATE SESSION ADMINISTER DATABASE TRIGGER DROP ANY OUTLINE CREATE ANY CONTEXT CREATE ANY INDEXTYPE CREATE ANY MATERIALIZED VIEW GRANT ANY ROLE DROP ANY ROLE CREATE PUBLIC DATABASE LINK CREATE DATABASE LINK DROP ANY VIEW CREATE ANY VIEW DROP PUBLIC SYNONYM DROP USER 80行が選択されました。   ユーザーの作成・削除といったアカウント管理から、全てのスキーマへの表の作成・削除・参照・更新・削除といったほぼデータベース管理者に近いデータ操作権限が割り当てられてしまいます。 もちろん業務上これらの操作が必要であればロールは割り振らなくてはいけないのですが、必要な時に付与し作業が終わったら剥奪する、付与したユーザーの操作を監査する、エクスポート/インポートバッチ専用ユーザーに付与しバッチの中に処理をコーディングし運用ツールからバッチを呼び出す形で定形処理しかできないようにするなど、このロールを付与されたユーザーが自由にアドホックな処理ができないような仕組みを作るような工夫をするように考慮して下さい。 「もくじ」にもどる

Oracle Databaseでは論理バックアップを取得するためにエクスポート/インポートの仕組みを提供しています。ユーザーが自分のスキーマのオブジェクトをエクスポートする際にはダンプファイルを出力するディレクトリへの書込み権限以外データにアクセスする権限を特に追加...

アクセス制御

[第17回] SELECT ANY TABLEシステム権限を使わないために

最小権限の原則を実現するためには、全てのユーザーの表にアクセス可能になるSELECT ANY TABLE権限などのANYシステム権限の付与に注意が必要なこは何回か紹介してきました。 しかし、特定のデータベーススキーマのデータを管理するために、スキーマ内の全ての表に対して権限を与えたいこともあります。それが複数のスキーマだったり、アプリ改修で表が増えたりすると、権限の付与が大変で、結局利便性のためにSELECT ANY TABLE権限を利用してしまうケースもあるかもしれません。 では、大量の表に対して一度に権限を付与することはできないでしょうか? 方法のひとつとして以下のようなPL/SQLプログラムの利用が考えられます。 ここでは、PUKUというスキーマの全ての表のSELECT権限をPUKU_ROというロールに付与するSQL文を自動生成する例です。 (注:このSQL/SQLプログラムはデータベース管理者で実行することを想定しています。行が画面からはみ出してしまっている場合にはお手数ですが、テキストエディタなどにコピペしてください。) set serveroutput on declare   objectOwner varchar2(64) := 'PUKU';   grantee varchar2(64) := 'PUKU_RO'; begin   for cur in ( select table_name from dba_tables where owner=objectOwner ) loop     dbms_output.put_line('grant select on ' || objectOwner || '.' || cur.table_name || ' to ' || grantee || ';');   end loop; end; / 実行すると以下のGRANT文が生成されます。 SQL> set serveroutput on SQL> declare   2    objectOwner varchar2(64) := 'PUKU';   3    grantee varchar2(64) := 'PUKU_RO';   4  begin   5    for cur in ( select table_name from dba_tables where owner=objectOwner ) loop   6      dbms_output.put_line('grant select on ' || objectOwner || '.' || cur.table_name || ' to ' || grantee || ';');   7    end loop;   8  end;   9  / grant select on PUKU.TEST to PUKU_RO; grant select on PUKU.CUSTOMER to PUKU_RO; grant select on PUKU.ORDER to PUKU_RO; grant select on PUKU.M_BOM to PUKU_RO; grant select on PUKU.M_ZIPCODE to PUKU_RO; grant select on PUKU.M_COMPANYCODE to PUKU_RO; PL/SQLプロシージャが正常に完了しました。  さらにEXECUTE IMMEDIATE文を利用すると、一気にGRANT文の実行までおこなうこともできます。 declare   objectOwner varchar2(64) := 'PUKU';   grantee varchar2(64) := 'PUKU_RO'; begin   for cur in ( select table_name from dba_tables where owner=objectOwner ) loop     execute immediate 'grant select on ' || objectOwner || '.' || cur.table_name || ' to ' || grantee;   end loop; end; /  既に権限が付与されている表に対して再度同じ権限を付与するGRANT文を発行しても、SQL文は正常に終了しますので、このPL/SQLプログラムは何度でも実行することができます。対象スキーマの表構成を変更した後にこのPL/SQLプログラムを実行すれば、簡単に権限付与することができます。 このPL/SQLプログラムは、DBA_TABLESデータディクショナリビューにアクセスしていますので、データベース管理者で実行する必要があります。DBA_TABLESデータディクショナリビューでは、すべてのスキーマの表の情報がリストされますので、検索条件を「OWNER = 'スキーマ名'」から「OWNER IN ('スキーマ1', 'スキーマ2')]というように変更することで複数スキーマの全ての表へのオブジェクト権限を一度に付与することもできます。また、DBA_TABLESデータディクショナリビューの代わりに、USER_TABLESデータディクショナリビューを利用すれば、データベース管理者ではなくオブジェクトの所有者アカウントを利用してPL/SQLプログラムを実行できます。 さらに検索条件に「TABLE_NAME LIKE 'M\_%'」(表名が「M_」から開始する)という条件を追加することで、スキーマ内の特定の表(今回はマスター表)のみの権限を付与するように書き換えることもできます。 set serveroutput on declare   grantee varchar2(64) := 'PUKU_RO'; begin   for cur in ( select table_name from user_tables where table_name like 'M\_%' ) loop     dbms_output.put_line('grant select on ' || cur.table_name || ' to ' || grantee || ';');   end loop; end; /  実行結果は以下の通りです。 SQL> show user ユーザーは"PUKU"です。 SQL> set serveroutput on SQL> declare   2    grantee varchar2(64) := 'PUKU_RO';   3  begin   4    for cur in ( select table_name from user_tables where table_name like 'M\_%' ) loop   5      dbms_output.put_line('grant select on ' || cur.table_name || ' to ' || grantee || ';');   6    end loop;   7  end;   8  / grant select on M_BOM to PUKU_RO; grant select on M_ZIPCODE to PUKU_RO; grant select on M_COMPANYCODE to PUKU_RO; PL/SQLプロシージャが正常に完了しました。  表の名前付けを規則性を持ったルール化していると、このように権限付与でも管理性が向上します。 また、どのユーザーやロールにどの権限が付与されているかのリストを確認するときにも、不要な権限が付与されているのに気付きやすくなります。 今回は強力なANYシステム権限を利用せずに必要な表へのアクセス権限をまとめたロールを簡単に作成する方法を紹介しました。もちろん今回紹介したものだけで、必ずしもANYシステム権限を使わないですむようになるわけではありませんが、いろいろ工夫をして最小権限の原則の実現を実現させてください。 「もくじ」にもどる

最小権限の原則を実現するためには、全てのユーザーの表にアクセス可能になるSELECT ANY TABLE権限などのANYシステム権限の付与に注意が必要なこは何回か紹介してきました。 しかし、特定のデータベーススキーマのデータを管理するために、スキーマ内の全ての表に対して権限を与えたいこともあります。それが複数のスキーマだ...

ID管理・認証

[第16回] アプリケーション用のユーザー

データベースのアカウントの分類方法は様々ありますが、どのように利用されることを目的として作成されたかという観点からだと下記の3つに分類できます。   アプリケーション用のユーザー(人間が使わないアカウント) 直接データベースにログインして利用するユーザー(人間が利用するアカウント) デフォルトで最初から作成されているユーザー(運用フェーズでは誰も利用すべきでなないアカウント)   ここではまずアプリケーション用のユーザーの作り方の考え方を説明します。もちろん、これが唯一無二の方法ではありませんが、セキュリティを担保するためのデータベースユーザー作成の考え方のひとつとして参考にしていただければと思います。 まず、アプリケーションで利用するデータを格納するスキーマのアカウントと、アプリケーションから接続するアカウントは別にすべきです。データを格納するスキーマのアカウント、つまりデータを格納する表の所有者は基本的に自分が所有している表に対して全ての権限を持っています。マスター表やSOX関連の更新されてはいけないデータに対してアクセスを制限することができません。そのためアプリケーションやバッチプログラムでデータベースに接続する際には、故意もしくはミスによるデータ破壊を防ぐためにも、それぞれのアプリケーション、バッチで必要な権限のみを持つアカウントを個別に作成しそのアカウントでアクセスさせたほうが安全です。ただし、アカウントを細分化していくと管理が大変になるので、そのシステムや格納しているデータの重要度とシステム管理の容易性をはかりにかけてアカウントを分割して下さい。 作成したアカウントのパスワードは容易に想像できない複雑なものにして、人に知られない事が重要です。開発テスト環境をそのまま本番環境に移行する場合には、本番移行時にパスワードを変更するようにしましょう。開発やテストの担当者(委託された外部の業者の可能性もあります)が本番システムにアクセスできてしまう事になります。開発者自身がネットワーク的な制限などで本番データベースにアクセスできない状態でも、本番環境のパスワードが広く知られている状態なのは危険です。本番移行時にパスワードを変更するためには、どこにパスワード情報が設定されているかを把握しておくことが大切です。パスワードがどこに保存されているか分からないので、アプリケーション用のユーザーのパスワード変更ができない、というシステムを非常によく見かけます。パスワードに関してはもう1点、パスワードがバッチスクリプトや設定ファイルに平文で保存しないようにしてください。情報漏洩の原因の上位に認証情報の盗難があげられます。重要なデータへのアクセス権限を多く持つアプリケーション用のユーザーの認証情報は特に注意が必要です。アプリケーションやバッチは安全に認証情報を保管できるミドルウェアや運用監視ツールから実行するようにしてください。 最後にアプリケーションユーザーへの権限の付与に関してです。 一番の注意点は強力なシステム権限やロールを付与しないことです。たとえば、SELECT ANY TABLE、CREATE ANY TABLEなどの他ユーザーの全てのオブジェクトにアクセスできるANYシステム権限やそれを含むEXP_FULL_DATABASE、DBAなどのロールです。 基本的には必要なオブジェクトへのオブジェクト権限を付与するようにしてください。ユーザーに直接、オブジェクト権限を付与することもできますが、業務処理ごとに必要なオブジェクト権限をまとめたロールを作成して、それをユーザーに付与することもできます。 アプリケーション用のユーザーにデータベースに接続するためのCREATE SESSIONシステム権限とオブジェクト権限(をまとめたロール)以外を付与する場合には、その権限が本当に必要かどうか、その権限を付与することで不要な操作がされる可能性はないかどうかを確認するようにしてください。 アプリケーションが利用するユーザーは、多くのデータに対するアクセス権限を持っています。アカウント情報が漏洩してしまった場合の影響は大きいので、厳密に管理して下さい。 「もくじ」にもどる

データベースのアカウントの分類方法は様々ありますが、どのように利用されることを目的として作成されたかという観点からだと下記の3つに分類できます。   アプリケーション用のユーザー(人間が使わないアカウント) 直接データベースにログインして利用するユーザー(人間が利用するアカウント) デフォルトで最初から作成されているユーザー(運用フェーズでは誰も利用すべきでなないアカウント)   ここではまずアプリケーション...

アクセス制御

[第15回] 最小権限の原則の実現のための考え方 ~ アクセスマトリックスとロール

操作ミスや悪意ある不正アクセスを防ぐためには、そもそもユーザーに必要以上の権限を付与しない事が重要です。 必要以上の権限を付与しないためには、そもそもどのユーザーが業務上どんな操作をする必要があるのかをまとめることが重要になります。誰がどのような権限を持つかをまとめるためのひとつの方法にアクセスマトリックスの作成があります。 簡単なアクセスマトリックスの例は以下の通りです。それぞれのユーザーがそれぞれの表に対してどのような操作をする必要があるかどうかをまとめています。    ユーザー 商品情報表  オーダー表 顧客情報表 Aさん SELECT INSERT UPDATE DELETE SELECT INSERT UPDATE DELETE SELECT INSERT UPDATE DELETE Bさん SELECT INSERT UPDATE DELETE ×  × Cさん SELECT SELECT SELECT このようにまとめられるとどのユーザーにどの権限を付与すればよいのか一目瞭然なのですが、どのユーザーがどの表にアクセスする必要があるのかをいきなりまとめるのは難しいかもしれません。 ここで、ユーザーと表の間に中間に「業務」という概念を入れてみます。 たとえばそれぞれのユーザーが以下のような業務を担当しているとします。   ユーザー 業務  Aさん アプリケーションデータ全体の管理 Bさん 商品情報の管理 Cさん 商品の顧客への出荷 また、それぞれの業務で必要な表へのアクセス権限をまとめます。   業務 商品情報表 オーダー表 顧客情報表 アプリケーションデータ全体の管理 SELECT INSERT UPDATE DELETE SELECT INSERT UPDATE DELETE SELECT INSERT UPDATE DELETE 商品情報の管理 SELECT INSERT UPDATE DELETE × × 商品の顧客への出荷 SELECT SELECT SELECT ユーザーと表への間にひとつの概念を加えることでどのユーザーにどの表へのアクセス権限を付与すればよいのかが分かりやすくなりました。また、同じ業務を担当している人には同じ権限を付与すればよいので、これらの表へのアクセス権限はまとめて名前をつけておくと便利です。このように権限をまとめたものがロールです。今回は「業務」ごとに必要な要件をまとめたロールを作成しています。 では、どのユーザーがどの業務を担当しているのか、というマッピングを自動化することはできないでしょうか? ユーザーと業務のマッピングは、そのユーザーの「所属」や「役職」などによってある程度は自動化できるかもしれません。たとえば、Aさんは「アプリケーション管理部門」の「責任者」なので、「アプリケーションデータ全体の管理」を担当している、といったように決められることもあるでしょう。 このようにロールを多段に構成することで権限の管理を簡単にすることができます。ロールが多段になった場合には、「所属」や「役職」などに対応するロールを「ビジネスロール」、「業務」ごとに権限をまとめたロールを「ITロール」や「アプリケーションロール」と呼び分けることもあります。(ロールの呼び方や定義に関しては様々な考え方があるので、ひとつの考え方として参考にしてください。) ロールを多段で管理する場合、ビジネスロールとITロールを両方ともデータベース内で管理する事もできますが、もし外部にID管理の仕組みがある場合、ITロールはOracle Database内のロールとして実装し、ビジネスロールはID管理製品で管理するというように分けて管理することもできます。 ロール管理に関しては日本ネットワークセキュリティ協会(JNSA)の「エンタープライズロール管理解説書」が参考になるのでこちらもぜひ参照ください。 このエントリはそれぞれのユーザーがどの表にアクセスできるか、という観点で最小権限の原則の実現のためには、アクセスマトリックスの作成をおこなうべきで、アクセスマトリックスを作成する際にはロールという概念をとりいれるとアクセスマトリックスをまとめやすい事を紹介しました。しかし、実際のアプリケーションではアプリケーション用の代表ユーザーが接続しているコネクションプールを使用することが多く、ユーザーが直接データベースにログインして表にアクセスすることは少ないです。また、データベースに直接ユーザーがアクセスするのは表へのアクセスというよりは、データベース管理操作をおこなうためであることも多いです。アプリケーションが利用するアカウントや、データベース管理操作をおこなうためのアカウントでどのように最小権限の原則を実現していくかは別のエントリで紹介します。 「もくじ」にもどる

操作ミスや悪意ある不正アクセスを防ぐためには、そもそもユーザーに必要以上の権限を付与しない事が重要です。 必要以上の権限を付与しないためには、そもそもどのユーザーが業務上どんな操作をする必要があるのかをまとめることが重要になります。誰がどのような権限を持つかをまとめるためのひとつの方法にアクセスマトリックスの作成があります。 簡単なアクセスマトリックスの例は以下の通りです。それぞれのユーザーがそれぞれ...

データベースセキュリティ

[第14回] 実際の利用者をデータベースに伝播する ~ セッション情報

最近のアプリケーションは利用者は直接データベースに接続するのではなく、利用者はアプリケーションサーバーに接続し、アプリケーションサーバーがデータベースに接続することがほとんどです。いわゆる3層アーキテクチャというやつです。 この場合、データベースへはアプリケーションサーバーが接続します。アプリケーション用のひとつの代表アカウントでデータベースに接続してコネクションプールを作成し、すべての利用者はこのコネクションプールを共用します。 データベースからはすべての利用者が同じデータベースユーザーによる接続として見えるため、データベースはその問い合わせを要求したのが実際にどの利用者かを識別できません。 そのため、データベース側で利用者ごとのアクセス制御をおこなうことや、アクセス監査をとった時に実際にどの利用者がそのアクセスをおこなったかの識別をおこなうことが難しくなっています。 Oracle Databaseでは、アプリケーションからデータベースに実際の利用者の情報を伝達する手段として、クライアント識別子(Client Identifier)を提供しています。アプリケーションで現在の利用者名を設定すると、データベースではSYS_CONTEXT関数を利用して以下のように取得できます。 SQL> select sys_context('userenv','client_identifier') from dual; SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') -------------------------------------------------------------------------------- tofukuda  実際の利用者が誰だか分かることで、仮想プライベートデータベース(VPD: Virtual Private Database)やData Redaction機能で利用者ごとのアクセス制御をデータベース側に実装することができます。また、CLIENT_IDENTIFIERの値は、標準監査の監査証跡を確認するためのDBA_AUDIT_TRAILビューのCLIENT_ID列、12cからの統合監査の監査証跡を確認するためのUNIFIED_AUDIT_TRAILビューのCLIENT_IDENTIFIER列に格納されますので、データベースのアクセス監査証跡だけで実際にどの利用者がデータにアクセスしたかを確認することもできるようになります。 クライアント識別子は非常に便利な機能ですが、アプリケーション側で現在の利用者が誰かをデータベースに伝播するためのロジックを組み込む必要があります。 たとえば、PL/SQLの場合、DBMS_SESSIONパッケージのSET_IDENTIFIERプロシージャを利用します。 SQL> exec dbms_session.set_identifier('tofukuda'); PL/SQLプロシージャが正常に完了しました。 また、Javaアプリケーションでは、利用するJDBCのバージョンによって設定方法が異なります。 JDBC 11gの場合 String metrics[] =    new String[OracleConnection.END_TO_END_STATE_INDEX_MAX]; metrics[OracleConnection.END_TO_END_CLIENTID_INDEX] = "tofukuda"; conn.setEndToEndMetrics(metrics, (short) 0); JDBC 12cの場合 conn.setClientInfo("E2E_CONTEXT.CLIENT_IDENTIFIER", "tofukuda"); コネクションプールを利用しているアプリケーションでは、コネクションプールを取得する際にクライアント識別子を設定する事になります。実際のアプリケーションの処理の流れはたとえば以下のようになります。 アプリケーション開始 前処理 コネクションプール取得 クライアント識別子の設定   データベース処理実行(SQL実行)   クライアント識別子の値の削除(オプション) コネクションプール開放 後処理 アプリケーション終了 アプリケーションへの変更はコネクションプールを取得する前にクライアント識別子を設定し、オプションでコネクションプールを開放する前に設定した値を消去します。フレームワークを利用している場合は、フレームワーク内にこのロジックを組み込むことで、アプリケーションの変更箇所を最小化できます。 WebLogic Serverを利用している場合には、設定だけでこの機能を利用することができます。 WebLogic Server 12cでは、データソース設定で「構成」タブの「アイデンティティ」タブで「接続時にクライアントIDを設定」と「データベース資格証明の使用」にチェックをつけてください。       また、データベースのバージョンが12cの場合には、アプリケーション側のweblogic.xmlに以下の権限設定を追加してください。 クラス名: oracle.jdbc.OracleSQLPermission ターゲット: clientInfo.OCSID.CLIENTID アクション: (空欄)     weblogic.xmlへの記載内容 <security-permission>   <security-permission-spec>     grant { permission oracle.jdbc.OracleSQLPermission "clientInfo.OCSID.CLIENTID", "" };   </security-permission-spec> </security-permission> なお、WebLogic Server 10.3を利用している場合やその他の注意点は、以下の2014/5/27に実施した「WebLogic Server勉強会」のスライドもあわせて参考にしてください。 機能の詳細に関しては、以下のblogやその関連記事も併せて参考にしてください。   [WLS] Data Source Security Part 3 [WLS] Data Source Security Part 5     Webブラウザのみを利用してWebアプリケーションを開発可能なApplication Express (APEX)を利用している場合も、APEXアプリケーションにログインする際のユーザー名とセッションIDがカンマ区切りテキストの形でセッション識別子に設定されます。 APEXアプリケーションでのクライアント識別子の値の例 PUKU:2644558331440 データベースが実際の利用者を知ることができると、アクセス制御や監査の精度があがります。 クライアント識別子は便利な機能なのでぜひご利用ください。 「もくじ」にもどる

最近のアプリケーションは利用者は直接データベースに接続するのではなく、利用者はアプリケーションサーバーに接続し、アプリケーションサーバーがデータベースに接続することがほとんどです。いわゆる3層アーキテクチャというやつです。この場...