11g リリース1（11.1）
E05781-03
 目次 |
 索引 |
| Oracle Database 2日でセキュリティ・ガイド 11g リリース1（11.1） E05781-03 |
|
この章の内容は次のとおりです。
Oracle Databaseには、データを保護する方法が多数用意されています。この章では、サイトでのデータの保護に使用できる次の方法について説明します。
ネットワーク上のデータを暗号化することもできます。この方法については「ネットワーク暗号化を使用したネットワーク上のデータの保護」を参照してください。
WHERE句を動的に追加するポリシーを作成し、データへのアクセスを制限します。VPDポリシーはデータベースの表またはビュー・レベルで作成および管理できます。データベースにアクセスするアプリケーションを変更する必要はありません。
透過的データ暗号化により、表領域または1つ以上の表の列をすばやく暗号化できます。実装も簡単で、他のタイプのデータベースの暗号化よりも多くの利点があります。
この項の内容は次のとおりです。
暗号化されたデータを読めるのは受信者のみです。暗号化を使用すると、オフサイトのストレージに送信されたバックアップ・メディアなど、保護されていない可能性のある環境でデータを保護できます。
暗号化されたデータには、次のコンポーネントがあります。
多くの場合、コンプライアンス規則を遵守するために機密データを暗号化します。たとえば、クレジット・カード番号、社会保障番号、病歴に関する情報などの機密データは、暗号化する必要があります。
データベース管理者からのデータへのアクセスを制限するため、これまでユーザーはデータの暗号化を求めてきました。しかし問題は暗号化よりも、むしろアクセス制御にあります。Oracle Database Vaultを使用してデータベース管理者からアプリケーション・データへのアクセスを制御することで、この問題に対処できます。
多くの場合、クレジット・カード番号や社会保障番号などの機密データは、バックアップ・テープやディスク・ドライバの紛失または盗難時にアクセスされないように暗号化します。近年では、ペイメント・カード産業（PCI）データ・セキュリティ標準や医療保険の相互運用性と説明責任に関する法律（HIPAA）などの業界規制に従って、クレジット・カード情報や医療情報の保護に暗号化がますます使用されています。
透過的データ暗号化を使用すると、個々の表列もしくは表領域全体を暗号化できます。ユーザーが暗号化された列にデータを挿入すると、透過的データ暗号化により、挿入されたデータが自動的に暗号化されます。ユーザーが列を選択すると、データは自動的に復号化されます。
透過的データ暗号化を使用してデータを暗号化するには、次のコンポーネントを作成します。
ALTER SYSTEMコマンドを使用して作成できます。ウォレットは、暗号化キーとしてパスワードを使用して暗号化できます。パスワードはウォレットの作成時に作成します。このため、ウォレットのコンテンツ（マスター・キー）へのアクセスは、パスワードを知っているユーザーに制限されます。ウォレットを作成したら、データベースがマスター暗号化キーにアクセスできるように、パスワードを使用してウォレットを開く必要があります。
sqlnet.oraファイルを変更して、ウォレットの場所を指定できます。
ユーザーが暗号化された列にデータを入力すると、Oracle Databaseにより次の手順が実行されます。
ユーザーがデータを選択した場合も、同じようなプロセスが実行されます。Oracle Databaseによりデータが復号化され、その後、データがクリア・テキスト形式で表示されます。
透過的データ暗号化には、次の利点があります。
透過型データ暗号化では、データが暗号化された列から取得されるときおよび暗号化された列に挿入されるときにのみ、パフォーマンスに影響します。暗号化されていない列に関する操作では、パフォーマンスが低下することはありません。これらの列が含まれる表に、暗号化された列が含まれている場合も同様です。暗号化されたデータは、クリア・テキスト・データより多くの記憶域を必要とします。平均的には、1つの列を暗号化すると、行ごとに32バイトから48バイトの記憶域が余分に必要になります。
透過的データ暗号化の使用を開始するには、ウォレットとマスター・キーのセットを作成する必要があります。ウォレットは、他のOracle Databaseコンポーネントと共有するデフォルトのデータベース・ウォレットを使用することも、特に透過的データ暗号化で使用される個別のウォレットを使用することもできます。オラクル社では、個別のウォレットを使用してマスター暗号化キーを格納することをお薦めします。このウォレットは、透過的データ暗号化により暗号化されるすべてのデータで使用されます。
次の手順を実行して、透過型データ暗号化を使用するように表列を設定します。
sqlnet.oraファイルでウォレットに対するディレクトリの場所を指定します。この手順は1回のみ実行します。
sqlnet.oraファイルのバックアップ・コピーを作成します。このファイルのデフォルトの場所は、$ORACLE_HOME/network/adminディレクトリです。
$ORACLE_HOMEディレクトリに、ウォレットを格納するディレクトリを作成します。たとえば、C:¥oracle¥product¥11.1.0¥db_1ディレクトリにORA_WALLETSという名前のディレクトリを作成します。
sqlnet.oraファイルの最後に、次のコードと同様のコードを追加します。ORA_WALLETSは、ウォレットを格納するディレクトリの名前を表しています。
ENCRYPTION_WALLET_LOCATION= (SOURCE= (METHOD=file) (METHOD_DATA= (DIRECTORY=C:¥oracle¥product¥11.1.0¥db_1¥ORA_WALLETS)))
sqlnet.oraファイルを保存して閉じます。
SYSとしてログオンし、AS SYSOPERで接続します。
SQLPLUS "SYS/AS SYSOPER" Enter password: password
SQL*Plusが起動し、デフォルトのデータベースに接続してから、SQL>プロンプトが表示されます。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
SHUTDOWN IMMEDIATE STARTUP
ウォレットを作成するには、ALTER SYSTEM SQL文を使用します。デフォルトでは、それまで使用されたマスター・キーの履歴がOracleウォレットに格納されます。これによりマスター・キーを変更でき、また、古いマスター・キーを使用して暗号化されたデータを復号化できます。大/小文字が区別されるウォレット・パスワードをデータベース管理者に知らせないことで、職務分離が実現されます。データベース管理者はデータベースを再起動できますが、ウォレットは閉じられており、ウォレット・パスワードを知っているセキュリティ管理者により手動で開かれる必要があります。
SYSTEMなどの管理権限を持つユーザーまたはセキュリティ管理者として接続します。次に例を示します。
CONNECT SYSTEM Enter password: password
ALTER SYSTEM文を入力します。passwordは、暗号化キーに割り当てるパスワードです。
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "password";
パスワードは二重引用符で囲みます。Oracle Databaseで作成した他のパスワードと同様に、パスワードはクリア・テキストまたは動的ビューや動的ログには表示されません。
この文により、新しい暗号化キーを使用するウォレットが生成され、このキーがデータの透過的な暗号化の現行のマスター・キーに設定されます。マスター暗号化キーを構成するために公開鍵基盤（PKI）を使用する場合は、証明書IDを指定します。証明書IDは、Oracleウォレットに格納される証明書の固有のIDを含む文字列です。次の構文を使用します。
ALTER SYSTEM SET ENCRYPTION KEY certificate_ID IDENTIFIED BY "password";
ウォレット・キーを作成した直後は、ウォレットは開かれており、いつでもデータの暗号化を開始できます。ただし、ウォレットを作成した後にデータベースを再起動した場合は、透過的データ暗号化を使用する前に手動でウォレットを開く必要があります。
ALTER SYSTEM文を入力します。passwordは、暗号化キーに割り当てたパスワードです。
ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "password";
ほとんどの場合、ウォレットを閉じるためのセッションが必要がないかぎり、ウォレットは開いたままにしておきます。マスター・キーへのアクセスを無効にし、暗号化された列へのアクセスを防止する場合は、ウォレットを閉じることができます。ただし、暗号化されていないデータは使用可能です。透過的データ暗号化を実行するには、ウォレットが開かれている必要があります。ウォレットを再度開くには、ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY password文を使用します。
sqlnet.oraファイルでウォレットのディレクトリの場所を作成し、ウォレット自体を作成したら、個々の表列もしくは表領域全体のいずれかを暗号化できます。
この項の内容は次のとおりです。
どの列を暗号化の対象として指定するかは、政府によるセキュリティ規則（カリフォルニア州上院法案1386）もしくは企業（MasterCardやVISAなど）が使用するプライベート標準によって決定します。クレジット・カード番号、社会保障番号、その他の個人情報（PII）はこのカテゴリに分類されます。暗号化が必要な他のデータ（企業秘密、研究結果、従業員の給与、ボーナスなど）は、内部のセキュリティ・ポリシーで定義されます。いつデータを暗号化し、いつ暗号化しないかについては、「データを暗号化するタイミング」を参照してください。
暗号化する列を選択するには、次のガイドラインに従います。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ウォレット・キーの作成方法については、「手順2: ウォレットを作成する」を参照してください。既存のウォレット・キーを開くには、「手順3: ウォレットを開く（または閉じる）」を参照してください。
Database Controlを起動する手順については、『Oracle Database 2日でデータベース管理者』を参照してください。
SYSTEMまたはセキュリティ管理者の名前など）とパスワードを入力し、「ログイン」をクリックします。データベースのホームページが表示されます。
「表」ページが表示されます。
O%を使用します。）。表が「表」ページに示されている場合は、その表を選択して「編集」をクリックします。
「表の作成」または「表の編集」ページで、暗号化オプションを設定できます。
たとえば、OE.ORDERS表の列を暗号化する場合、「表の編集」ページは次のように表示されます。
索引付けされた列や、外部キー制約を使用する列（主キー列または一意キー列）は選択しないでください。これらの列は暗号化できません。これらの列には、名前の左側に鍵またはチェック・マーク・アイコンがあります。
「ランダムにキーを生成」設定はソルトを有効にします。ソルトは、暗号化されたデータのセキュリティを強化する方法で、暗号化される前のデータに追加されるランダムな文字列です。繰り返されるテキストが、暗号化されたときには異なって表示されます。ソルトによって、攻撃者は、暗号化されたテキストのパターン一致をデータの盗用に使用できなくなります。
表の作成（または「表の編集」 ）ページが表示されます。
列内の既存のデータおよび将来格納されるデータは、データベース・ファイルに書き込まれるときに暗号化され、認可されたユーザーが選択したときに復号化されます。表の更新時は、読取りアクセスのみが可能です。データ操作言語（DML）文が必要な場合は、オンラインで再定義できます。
新規表領域の作成中に新規表領域を暗号化することはできますが、既存の表領域を暗号化することはできません。回避策として、CREATE TABLE AS SELECT、ALTER TABLE MOVEを使用するか、またはOracle Data Pumpインポートを使用して既存の表領域からデータを取得し、暗号化されている表領域に格納することができます。表領域の作成の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
ウォレット・キーの作成方法については、「手順2: ウォレットを作成する」を参照してください。既存のウォレット・キーを開くには、「手順3: ウォレットを開く（または閉じる）」を参照してください。
Database Controlを起動する手順については、『Oracle Database 2日でデータベース管理者』を参照してください。
SYSTEMまたはセキュリティ管理者の名前など）とパスワードを入力し、「ログイン」をクリックします。データベースのホームページが表示されます。
「表領域」ページが表示されます。
暗号化アルゴリズムの詳細は、「ネットワーク暗号化の設定」の手順5の「使用可能なメソッド」を参照してください。
「表領域の作成」ページが表示されます。
既存の表領域のリストに新規表領域が表示されます。既存の表領域は暗号化できないことに注意してください。
|
関連項目:
|
すでに暗号化されているデータについて、データベースに問い合せることができます。暗号化された個々の列、暗号化された列を含む現行のデータベース・インスタンスのすべての表、暗号化されているすべての表領域をチェックできます。
この項の内容は次のとおりです。
V$ENCRYPTION_WALLETビューを実行することで、ウォレットが開いているか閉じているかを確認できます。
V$ENCRYPTION_VIEWビューを次のように実行します。
SELECT * FROM V$ENCRYPTION_WALLET;
ウォレット・ステータスが次のように表示されます。
WRL_TYPE WRL_PARAMETER STATUS -------- ---------------------------------------- ------- file C:\oracle\product\11.1.0\db_1\wallets OPEN
SQL*PlusでDESC（DESCRIBE）文を使用して、データベース表内の暗号化されている列をチェックします。
DESC文を実行します。
DESC tablename;
次に例を示します。
DESC OE.ORDER_ITEMS;
表スキーマの説明が表示されます。次に例を示します。
Name Null? Type ---------------------------------------- -------- -------------------------- ORDER_ID NOT NULL NUMBER(12) LINE_ITEM_ID NOT NULL NUMBER(3) PRODUCT_ID NOT NULL NUMBER(6) UNIT_PRICE NUMBER(8,2) QUANTITY NUMBER(8) ENCRYPT
暗号化されているすべての表列をチェックするには、DBA_ENCRYPTED_COLUMNSビューを使用します。
DBA_ENCRYPTED_COLUMNSビューから選択します。次に例を示します。
SELECT * FROM DBA_ENCRYPTED_COLUMNS;
このSELECT文によって、Oracle Transparent Data Encryptionを使用して暗号化された列を含む、データベースのすべての表および列がリストされます。次に例を示します。
OWNER TABLE_NAME COLUMN_NAME ENCRYPTION_ALG SALT ----------- ---------- ----------- ---------------- ---- OE CUSTOMERS INCOME_LEVEL AES 128 bits key YES OE UNIT_PRICE ORADER_ITEMS AES 128 bits key YES HR EMPLOYEES SALARY AES 192 bits key YES
表6-1に、暗号化されている表領域のチェックに使用できるデータ・ディクショナリ・ビューを示します。
Oracle Virtual Private Database（VPD）では、ユーザーが実行する任意のSQL文にWHERE句を動的に追加することができます。WHERE句により、ユーザーの資格証明に基づいて、ユーザーがアクセスを許可されているデータがフィルタ処理されます。
この項の内容は次のとおりです。
Oracle Virtual Private Database（VPD）は、データベースの表またはビュー・レベルの行レベル・セキュリティを提供します。これを拡張して列レベル・セキュリティを提供することもできます。基本的に仮想プライベート・データベースは、仮想プライベート・データベースのセキュリティ・ポリシーの適用対象である表またはビューで使用される、任意のSQL文に追加的なWHERE句を挿入します（セキュリティ・ポリシーはデータへのアクセスを許可または阻止する機能です）。WHERE句では、セキュリティ・ポリシーを通過した資格証明を持つ、すなわち、保護する対象のデータへのアクセス権を持つユーザーのみが許可されます。
Oracle Virtual Private Databaseのポリシーには次のコンポーネントがあり、通常はセキュリティ管理者のスキーマに作成されます。
SELECT文が変換されます。
SELECT * FROM orders;
この文は次のように変換されます。
SELECT * FROM orders WHERE SALES_REP_ID = 159;
この例では、ユーザーが表示できるのは、販売担当者159による注文のみです。このWHERE句の生成に使用されるPL/SQLファンクションは次のようになります。
この例では、次のとおりです。
OEと表名ORDERSを格納するパラメータが作成されます。（表に対する2番目のパラメータtable_varは、ビューおよびシノニムにも使用できます。）これらの2つのパラメータは、常にこの順序で作成されます。つまり、スキーマのパラメータが最初に作成され、その後、表、ビューまたはシノニム・オブジェクトのパラメータが作成されます。ファンクション自体では、OEスキーマ、またはそのORDERS表は指定されないことに注意してください。作成する仮想プライベート・データベース・ポリシーでは、OE.ORDERS表の指定にこれらのパラメータが使用されます。
WHERE述語句に使用される文字列を返します。
WHERE SALES_REP_ID = 159述語の作成が含まれます。
WHERE句は、ユーザーのセッション情報（ユーザーIDなど）に基づいてユーザー情報をフィルタ処理するよう構成できます。これを行うには、アプリケーション・コンテキストを作成します。アプリケーション・コンテキストは、名前と値のペアです。次はその例です。
SELECT * FROM oe.orders WHERE sales_rep_id = SYS_CONTEXT('userenv','session_user');
この例では、WHERE句でSYS_CONTEXT PL/SQLファンクションを使用して、userenvコンテキストによって示されるユーザーのセッションID（session_user）を取得しています。アプリケーション・コンテキストの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
DBMS_RLS.ADD_POLICY関数を使用して、パッケージにポリシーを追加します。DBMS_RLS PL/SQLパッケージを使用するには、そのPL/SQLパッケージに対するEXECUTE権限を付与される必要があります。ユーザーSYSがDBMS_RLSパッケージを所有しています。
データベース・レベルで行レベルのセキュリティを強制する方法は、アプリケーション・プログラム・レベルでセキュリティを強制した場合に比べて多くのメリットがあります。データを保護する場所であるデータベース自体にセキュリティ・ポリシーを実装できるため、様々な方法でアクセスされた場合でも攻撃を受ける可能性が低くなります。このセキュリティは、ユーザー（侵入者）がどれだけデータへのアクセスを試行しても存在し、強制されます。データベースに接続するすべてのアプリケーションでポリシーを維持する必要はなく、1箇所（データベース）のみでポリシーを維持できるため、メンテナンス費も低く抑えられます。固有のDML操作に対してポリシーを作成できるため、非常に柔軟性の高いポリシーを適用できます。
注文入力データベースのOEのORDERS表には次の情報が含まれています。
Name Null? Type -------------------------------------- -------- --------------------------------- ORDER_ID NOTNULL NUMBER(12) ORDER_DATE NOTNULL TIMESTAMP(6) WITH LOCAL TIME ZONE ORDER_MODE VARCHAR2(8) CUSTOMER_ID NOTNULL NUMBER(6) ORDER_STATUS NUMBER(2) ORDER_TOTAL NUMBER(8,2) SALES_REP_ID NUMBER(6) PROMOTION_ID NUMBER(6)
表を問い合せる個人に基づいて表へのアクセスを制限すると想定します。たとえば営業担当者は作成された注文のみを確認でき、他の従業員は確認できないようにします。このチュートリアルでは、営業担当者のユーザー・アカウントと財務管理者のアカウントを作成し、ロールに基づいてデータ・アクセスを制限するOracle Virtual Private Databaseを作成します。
作成する仮想プライベート・データベース・ポリシーは、PL/SQLファンクションに関連付けられます。VPDポリシーはPL/SQLファンクションまたはプロシージャによって制御されるため、アクセスを制限するポリシーを様々な方法で設計できます。このチュートリアルでは、直属の上司が誰であるかに基づいて従業員のアクセスを制限するファンクションを作成します。このファンクションでは、顧客のIDに基づいて顧客のアクセスが制限されます。
データベース管理者やアプリケーション・アカウントとは別のデータベース・アカウントにVPDポリシーを格納する場合があります。このチュートリアルでは、「チュートリアル: セキュア・アプリケーション・ロールの作成」で作成したsec_adminアカウントを使用してVPDポリシーを作成します。アプリケーション表とVPDポリシーを分けることで、セキュリティを高めます。
行データの機密性に基づいてアクセスを制限するには、Oracle Label Security（OLS）を使用します。OLSを使用すると、様々なレベルのセキュリティでデータを分類できます。この場合、行内のデータにアクセスできるユーザーをレベルごとに設定できます。この方法では、データのアクセス制御は、ユーザーの権限ではなくデータ自体に焦点が当てられます。詳細は、「Oracle Label Securityによる行レベルのセキュリティの強制」を参照してください。
このチュートリアルでは、次の手順を実行します。
「チュートリアル: セキュア・アプリケーション・ロールの作成」で、チュートリアルで使用するためにsec_adminというセキュリティ管理者アカウントを作成しました。このチュートリアルでも、このアカウントを使用できます。まだこのアカウントを作成していない場合は、「手順1: セキュリティ管理者アカウントを作成する」の手順を実行して、sec_adminを作成します。
sec_adminアカウント・ユーザーには、DBMS_RLSパッケージを使用するための権限が必要です。このパッケージはSYSが所有しているため、このパッケージ権限をsec_adminに付与するには、SYSとしてログオンする必要があります。また、sec_adminユーザーには、OEスキーマのCUSTOMERS表およびHRスキーマのEMPLOYEES表に対するSELECT権限も必要です。
Database Controlを起動する手順については、『Oracle Database 2日でデータベース管理者』を参照してください。
SYSユーザーとしてログインし、SYSDBA権限で接続します。
「ユーザー」ページが表示されます。
「ユーザーの編集」ページが表示されます。
「パッケージオブジェクト権限の追加」ページが表示されます。
SYS.DBMS_RLSと入力し、sec_adminにDBMS_RLSパッケージへのアクセス権を与えます。
「ユーザーの編集」ページが表示されます。
「表オブジェクト権限の追加」ページが表示されます。
HR.EMPLOYEESと入力し、sec_adminにHR.EMPLOYEES表へのアクセス権を付与します。
「ユーザーの編集」ページが表示されます。
OE.ORDERS表へのアクセスを必要とする従業員のための、ユーザー・アカウントを作成する準備ができました。
「ユーザー」ページが表示されます。
「ユーザーの作成」ページが表示されます。
LDORAN（Louise Doranのユーザー・アカウントを作成するため）
デフォルト
パスワード
USERS
TEMP
ロック解除
LDORANが新しいユーザーとして表示された状態で「ユーザー」ページが表示されます。
「ユーザーの編集」ページが表示されます。
「表オブジェクト権限の追加」ページが表示されます。
OE.ORDERS
このテキストにはスペースを含めないでください。
OE.ORDERSのSELECT権限がリストされた状態で「ユーザーの作成」ページが表示されます。
「ユーザーの作成」ページが表示されます。
LPOPP（財務管理者のLuis Poppのユーザー・アカウントを作成するため）
両方の従業員アカウントが作成され、これらには同じ権限があります。一方がOE.ORDERS表でSELECT文を実行すると、すべてのデータを確認できます。
f_policy_ordersポリシーは、ORDERS表に問合せを行うユーザーのフィルタリングに使用される、ポリシーを定義するPL/SQLファンクションです。ユーザーをフィルタリングするために、ポリシー・ファンクションでは、データベースにログイン中のユーザーに関するセッション情報を取得するSYS_CONTEXT PL/SQLファンクションが使用されます。
sec_adminとしてログインします。
「ファンクション」ページが表示されます。
「ファンクションの作成」ページが表示されます。
F_POLICY_ORDERS
SEC_ADMIN
f_policy_ordersファンクションが、ユーザーのセッション情報を取得するSYS_CONTEXT PL/SQLファンクションを使用してこれを実行し、sec_adminがSELECT権限を持つHR.EMPLOYEES表にあるユーザーのジョブIDとこの情報を比較します。
この例では、次のとおりです。
schema）と表（tab）のパラメータを定義します。このファンクションはOE.ORDERS表を指定しません。「手順5: ACCESSCONTROL_ORDERS仮想プライベート・データベース・ポリシーを作成する」で作成したACCESSCONTROL_ORDERSポリシーによりこれらのパラメータが使用され、OEスキーマとschema表が指定されます。最初にschemaパラメータを作成し、その後にtabパラメータを作成してください。
WHERE述語句に使用される文字列を返します。この戻り値のデータ型としてはVARCHAR2が常に使用されます。
BEGIN句で開始するWHERE述語の作成が含まれます。
v_job_idおよびv_user変数をNULLに設定し、predicate変数を1=2、つまり誤った値に設定します。この段階では、変数が16行目から始まるテストに通るまで、WHERE述語は一切生成されません。
SYS_CONTEXTファンクションを使用してユーザーのセッション情報を取得し、v_user変数に記述します。
sa_rep（営業担当者）である場合は、predicate変数が1=1に設定されます。つまりユーザーは営業担当者であることになり、テストに通ります。
WHERE role_of_user_logging_on IS "sa_rep"に翻訳されるWHERE述語が返されます。このWHERE述語は、ユーザーLDORANとLPOPPがOE.ORDERS表に対して発行するSELECT文に追加されます。
EXCEPTION句が提供されます。
仮想プライベート・データベース・ポリシー・ファンクションの作成が終了したため、仮想プライベート・データベース・ポリシーaccesscontrol_ordersを作成し、これをORDERS表に追加できます。パフォーマンスを向上させるためCONTEXT_SENSITIVEパラメータをポリシーに追加します。これによって、アプリケーション・コンテキストの内容が変わった場合、このケースでは新しいユーザーがログオンした場合のみ、Oracle Databaseはf_policy_ordersファンクションを実行します。Oracle Databaseは、ユーザーがORDERS表でSQL SELECT文を実行したときのみポリシーをアクティブにします。INSERT、UPDATEおよびDELETE文は権限を付与されていないため、使用できません。
「仮想プライベート・データベース・ポリシー」ページが表示されます。
「ポリシーの作成」ページが表示されます。
ACCESSCONTROL_ORDERS
OE.ORDERS
CONTEXT_SENSITIVE」を選択します。最後にカーソルが使用されてからコンテキストが変更されている場合、このタイプは文の実行時にポリシー・ファンクションを再評価します。複数のクライアントが1つのデータベース・セッションを共有するセッション・プーリングの場合、クライアント切替え時に中間層でコンテキストをリセットする必要があります。Oracle Databaseは、このポリシー・タイプのファンクションにより戻された値をキャッシュしません。常に文の解析時にポリシー・ファンクションを実行します。CONTEXT_SENSITIVEポリシー・タイプは1つのオブジェクトのみに適用されます。
ポリシー・タイプを有効にするには、「有効」ボックスを選択します。
この段階では、それぞれのユーザーとしてログオンし、ORDERS表からのデータの選択を試すことで、accesscontrol_ordersポリシーをテストします。
コマンド・プロンプトで、次のコマンドを入力してSQL*Plusを起動し、販売担当者Louise Doran（ユーザー名はLDORAN）としてログインします。
SQLPLUS LDORAN Enter password: password
SQL*Plusが起動し、デフォルトのデータベースに接続してから、プロンプトが表示されます。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
SELECT文を入力します。
SELECT COUNT(*) FROM OE.ORDERS;
Louiseに関する次のような結果が表示されます。表示のとおり、LouiseはOE.ORDERS表のすべての注文にアクセスできます。
COUNT(*) -------- 105
CONNECT LPOPP Enter password: password
SELECT文を入力します。
SELECT COUNT(*) FROM OE.ORDERS;
Popp氏は営業担当者ではないので、OE.ORDERS表のデータへのアクセスがなく、次のような結果が表示されます。
COUNT(*) -------- 0
EXIT
このチュートリアルの終了後、使用したデータ構造が不要な場合は削除できます。
sec_adminとしてログインします。
「仮想プライベート・データベース・ポリシー」ページが表示されます。
作成したポリシーのACCESSCONTROL_ORDERSが表示されます。
「ユーザー」ページが表示されます。
sec_adminは削除しないでください。このマニュアルの以降のチュートリアルで、このアカウントが必要になります。
Oracle Label Security（OLS）は、データベース表に行レベルのセキュリティを提供します。セキュリティのレベルを定義する1つまたは複数のセキュリティ・ラベルを表のデータ行に割り当てることで、セキュリティを実装できます。
この項の内容は次のとおりです。
Oracle Label Securityを使用すると、データベース表を行レベルで保護でき、ニーズに応じて行を様々なセキュリティ・レベルに割り当てることができます。たとえば、非常に機密性の高いデータを含む行にはHIGHLY SENSITIVEというラベルを割り当て、機密性がそれほど高くないデータを含む行にはSENSITIVEというラベルを割り当てたりできます。すべてのユーザーがアクセスできる行にはPUBLICというラベルを割り当てます。ラベルは必要なだけ作成でき、使用する環境のセキュリティ要件に適合させることができます。
ラベルを作成して割り当てたら、Oracle Label Securityを使用して、これらのラベルに基づき特定の行に特定のユーザー認可を割り当てます。以降、Oracle Label Securityはデータ行のラベルとユーザーのセキュリティ・クリアランスを自動的に比較し、行のデータにユーザーがアクセスできるかどうかを決定します。
Oracle Label Securityポリシーには次のコンポーネントがあります。
SENSITIVEやHIGHLY SENSITIVEなどです。
Oracle Label Securityのラベルとポリシーは、Database Controlで作成するか、SA_SYSDBA、SA_COMPONENTS、SA_LABEL_ADMIN PL/SQLパッケージを使用して作成できます。PL/SQLパッケージの詳細は、『Oracle Label Security管理者ガイド』を参照してください。このマニュアルには、Database Controlを使用してOracle Label Securityのラベルとポリシーを作成する方法が記載されています。
たとえば、ユーザーがアプリケーション表のSELECT権限を持っているとします。次の図にあるように、ユーザーがSELECT文を実行すると、Oracle Label Securityは選択された各行を評価して、このユーザーがアクセスできるかどうかを決定します。決定は、セキュリティ管理者がユーザーに割り当てた権限とアクセス・ラベルに基づいて行われます。Oracle Label Securityを設定して、UPDATE、DELETE、INSERT文でもセキュリティ・チェックを行うことができます。
Oracle Label Securityポリシーを作成する前に、アプリケーション・スキーマにラベルを適用する場所と方法を決定する必要があります。
Oracle Label Securityポリシーを適用する必要がある表を特定します。多くの場合、Oracle Label Securityポリシーが必要となるアプリケーションの表は限られています。たとえば、ルックアップ値や定数を格納している表などは、通常セキュリティ・ポリシーで保護する必要はありません。ただし、患者の病歴や従業員の給与などの機密データを含む表は、ポリシーを使用して保護する必要があります。
表の特定後、表のデータを評価して、表のセキュリティ・レベルを決定します。分析のこの段階では、ビジネス活動について熟知しているユーザーの意見も参考にしてください。
データ・レベルはデータの機密性を表します。データ・レベルには、PUBLIC、SENSITIVE、HIGHLY SENSITIVEなどがあります。今後、機密性がどう変化するかも考慮する必要があります。そうすることで、強固なラベル定義が作成できます。
データ・レコードに割り当てられた機密性ラベルのレベル・コンポーネントが、ユーザーのクリアランスより低いレベルの場合、このレコードにアクセスするユーザーにはこの行へのアクセス権が付与されます。
データ・コンパートメントは主に、行政環境で使用されます。使用するアプリケーションが商業アプリケーションの場合、多くの場合はデータ・コンパートメントを作成しません。
データ・グループとデータ・コンパートメントは通常、組織、地域、データ所有者によってデータへのアクセスを制御するために使用されます。たとえば、アプリケーションが販売アプリケーションの場合、国または地域によって販売データへのアクセスを制御できます。
コンパートメントおよびグループと一緒に機密性ラベルがデータ・レコードに割り当てられた場合、このデータを読み取るユーザーは、データ・ラベル、データ・ラベルのすべてのコンパートメント、機密性ラベル内の少なくとも1つのグループのレベルと同等またはそれ以上のレベルのユーザー・クリアランスを持っている必要があります。グループは階層になっているため、データ・ラベルに割り当てられた機密性ラベルの1つのグループの親を所有している場合は、そのレコードにもアクセスできます。
ユーザーを複数のユーザー・タイプに分類します。たとえば、通常ユーザー、特権ユーザー、管理ユーザーのいずれかに指定します。ユーザーのカテゴリを作成したら、手順2で作成したデータ・レベルと比較します。カテゴリは、手順1で実行したスキーマ分析で識別した各表に正確に対応する必要があります。次に、ユーザー分布の組織構造を手順4で識別したデータ・グループと比較します。
Oracle Label Securityには、ユーザーに割り当てることのできる特別な認可が複数あります。多くの場合、通常ユーザーに特別な認可は必要ありません。認可の詳細は、『Oracle Label Security管理者ガイド』を参照してください。
この手順は企業全体の連続性を維持するために重要であり、ドキュメントは企業のセキュリティ・ポリシーの一部となります。たとえば、このドキュメントには保護されるアプリケーションのリストとその理由などが含まれます。
このチュートリアルでは、Oracle Label Securityを使用する一般的な方法を説明します。ここではHR.LOCATIONS表にセキュリティ・ラベルを適用します。ユーザーsking、kpartner、ldoranは、この表内の特定の行に対して、LOCATIONS表の都市に基づくアクセス権を持っています。
Oracle Label Securityを使用して、行データに焦点を当て、データの機密性に基づいて様々なアクセス・レベルを設計することにより、ユーザーによるデータ・アクセスを制限します。ユーザー権限または組織内のユーザーのジョブ・タイトルなどの他の方法に焦点を当ててユーザー・アクセスを制限する必要がある場合、仮想プライベート・データベース・ポリシーとともに使用するPL/SQLファンクションまたはプロシージャを作成できます。詳細は、「Oracle Virtual Private Databaseによるデータ・アクセスの制御」を参照してください。
HR.LOCATIONSのスキーマは次のようになります。
Name Null? Type ----------------------------------------- -------- ------------- LOCATION_ID NOT NULL NUMBER(4) STREET_ADDRESS VARCHAR2(40) POSTAL_CODE VARCHAR2(12) CITY NOT NULL VARCHAR2(30) STATE_PROVINCE VARCHAR2(25) COUNTRY_ID CHAR(2)
次のラベルを適用します。
| ラベル | 権限 |
|---|---|
|
|
ミュンヘン、オックスフォード、ローマに読取りアクセス権を付与します。 |
|
|
北京、東京、シンガポールに読取りアクセス権を付与します。 |
|
|
|
このチュートリアルでは、次の手順を実行します。
Oracle Label Securityは、Oracle Databaseのデフォルトのインストールではインストールされませんが、Oracle Databaseで使用可能な製品の一部です。Oracle Universal Installerを使用して既存のデータベースにインストールし、Database Configuration Assistant（DBCA）を使用して登録できます。Oracle Label Securityでは独自のユーザー・アカウントLBACSYSが提供され、このアカウントをインストール後に有効にする必要があります。
この手順では、既存のデータベースにOracle Label Securityをインストールする方法を説明します。
SQL*PlusにSYSとしてログインし、SYSOPER権限で接続します。SQLプロンプトで、次のコマンドを入力します。
SHUTDOWN IMMEDIATE
EXIT
「インストール・タイプの選択」ウィンドウが表示されます。
ホームの詳細の指定画面が表示されます。
デフォルトでは、新しいOracleホームを作成するよう提案されるため、既存の正しいOracleホームを選択する必要があります。その後、システムが最低要件を満たしているかどうかが確認されます。次に、「使用可能な製品コンポーネント」ウィンドウが表示されます。
このオプションは、Enterprise Editionのオプションの下にあります。「Oracle Services For Microsoft Transaction Server」が選択されていますが、不要な場合はこの選択を解除できます。次に、「次へ」をクリックします。
「サマリー」ウィンドウが表示されます。
進行状況ウィンドウが表示されます。インストールが完了すると、「インストールの終了」ウィンドウが表示されます。
$ORACLE_HOME/binディレクトリに移動し、次のコマンドを実行してデータベース・コンソールおよびリスナーを起動します。
./emctl start dbconsole ./lsnrctl start
SQL*Plusを起動し、データベース・インスタンスを再起動します。
SQLPLUS "SYS/AS SYSOPER" Enter password: password Connected to an idle instance SQL> STARTUP
orclである場合、この名前は次のようになります。
インストールが完了したら、Oracle Label SecurityをOracle Databaseに登録する必要があります。
dbca
一般的に、dbcaは$ORACLE_HOME/binディレクトリにあります。
または、次のコマンド・プロンプトでDatabase Configuration Assistantを起動できます。
dbca
Windowsでは一般的に、dbcaはORACLE_BASE¥ORACLE_HOME¥binディレクトリにあります。
「操作」ページが表示されます。
「データベース」ページが表示されます。
「管理オプション」ページが表示されます。
「セキュリティ設定」ページが表示されます。
このリリースの拡張セキュリティ設定を利用することをお薦めします。
「データベース・コンポーネント」ページが表示されます。
「接続モード」ページが表示されます。
Oracle Label Securityが登録され、データベース・インスタンスが再起動されます。
Oracle Label Securityのインストール・プロセスにより、Oracle Label Security機能を管理するデフォルトのユーザー・アカウントLBACSYSが作成されます。管理者は、このユーザーと同じ権限（SA_SYSDBA、SA_COMPONENTSおよびSA_LABEL_ADMIN PL/SQLパッケージに対するEXECUTE権限）を持つユーザーを作成できます。デフォルトでは、LBACYSは、パスワードの期限が切れている、ロックされたアカウントとして作成されます。次の手順では、LBACYSをロック解除し、新しいパスワードを作成します。ユーザーLBACSYSはDatabase Controlを使用してOracle Label Securityポリシーを作成しているため、SELECT ANY DICTIONARY権限をLBACSYSに付与する必要があります。
SYSTEMユーザーとしてDatabase Controlにログインします。「ログイン」ページでSYSTEMとSYSTEMに割り当てられたパスワードを入力します。「接続モード」を「標準」に設定します。「ログイン」を選択してログインします。
「ユーザー」ページが表示されます。
LBACSYSを選択します。LBACSYSを簡単に検索するには、「オブジェクト名」フィールドにlbaと入力し、「実行」をクリックします。
LBACSYSが選択された状態で、「編集」をクリックします。「ユーザーの編集」ページが表示されます。
セキュリティを考慮して、以前のリリースのOracle Databaseで使用していたパスワードと同じパスワードは使用しないでください。
「システム権限の変更」ページが表示されます。
SELECT ANY DICTIONARYを選択し、「移動」をクリックして「選択したシステム権限」リストに移動します。次に「OK」をクリックします。
ロールと3人のユーザーを作成し、これらのユーザーにロールを付与します。
emp_roleロールは、これから作成する3人のユーザーに必要な権限を付与します。
SYSTEMとしてログインしていることを確認します。SYSTEMとしてログインしていない場合、「ログアウト」を選択し、次に「ログイン」を選択します。「ログイン」ページでSYSTEMとこのアカウントに割り当てられたパスワードを入力します。「接続モード」を「標準」に設定します。「ログイン」を選択してログインします。
SYSTEMとしてログインしている場合、「データベース・インスタンス」リンクをクリックして、ホームページを表示します。
「ロール」ページが表示されます。
「ロールの作成」ページが表示されます。
EMP_ROLEと入力し、「認証」は「なし」のままにします。
「表オブジェクト権限の追加」ページが表示されます。
HR.LOCATIONSと入力し、HRスキーマのLOCATIONS表を選択します。次に「使用可能な権限」で、SELECTを「選択した権限」リストに移動します。
作成する3人のユーザーは、役職に基づき、HR.LOCATIONS表に対して異なるレベルのアクセス権を持ちます。Steven King（sking）は広報部長で、HR.LOCATIONS表への完全な読取りアクセス権を持ちます。Karen Partners（kpartner）は販売部マネージャでより制限されたアクセス権を持ち、Louise Doran（ldoran）は販売担当者でアクセス権が最も制限されています。
SYSTEMとしてログインしていることを確認します。SYSTEMとしてログインしていない場合、「ログアウト」を選択し、次に「ログイン」を選択します。「ログイン」ページでSYSTEMとこのアカウントに割り当てられたパスワードを入力します。「接続モード」を「標準」に設定します。「ログイン」を選択してログインします。
SYSTEMとしてログインしている場合、「データベース・インスタンス」リンクをクリックして、ホームページを表示します。
「ユーザー」ページが表示されます。
「ユーザーの作成」ページが表示されます。
SKING
デフォルト
USERS
TEMP
「リストを編集」を選択してemp_roleロールをskingに付与します。「使用可能なロール」リストからemp_roleを選択し、「移動」をクリックして「選択したロール」リストに移動します。「OK」をクリックします。「ユーザーの作成」ページで、CONNECTロールとemp_roleロールの両方で「デフォルト」ボックスが選択されていることを確認します。
CREATE SESSION権限を付与します。skingにはADMIN OPTIONオプションを付与しないでください。
SKINGを選択し、「アクション」を「類似作成」に設定して「実行」をクリックします。「ユーザーの作成」ページが表示されます。
kpartnerおよびldoranのアカウントを作成します。名前とパスワードを作成します。（「パスワードの作成要件」を参照してください。）ロールやシステム権限を付与する必要はありません。これらのアカウントのロールおよびシステム権限は、skingアカウントで定義され、自動的に作成されます。
この段階で、同じ権限を持つ3人のユーザーが作成されました。これらすべてのユーザーには、HR.LOCATIONS表に対するSELECT権限があります。
ここでは、ACCESS_LOCATIONSポリシーを作成します。
LBACSYSとしてDatabase Controlにログインします。「ログアウト」を選択し、次に「ログイン」を選択します。「ログイン」ページで、ユーザーLBACSYSとしてログインします。「接続モード」を「標準」に設定します。「ログイン」を選択してログインします。
「Label Securityポリシー」ページが表示されます。
ACCESS_LOCATIONS
OLS_COLUMN以降で、表にポリシーを適用するときに、このラベル列が表に追加されます。デフォルトでは、ポリシー・ラベル列のデータ型はNUMBER(10)です。
通常、ラベル列は非表示にしますが、開発段階ではチェックできるように表示しておきます。ポリシーの作成が完了し、使用が開始された後、アプリケーションから見えないようにこの列は非表示にします。
すべての問合せ用(READ_CONTROL)
ラベル列のUPDATE操作にセッションのデフォルト・ラベルを使用(LABEL_DEFAULT)
ACCESS_LOCATIONSポリシーが「Label Securityポリシー」ページに表示されます。
この段階では、ポリシーが作成され、ポリシーの強制オプションが設定されています。次に、ポリシーで使用するラベル・コンポーネントを作成します。
少なくとも、PUBLICまたはSENSITIVEなど、1つ以上のレベルを作成し、詳細名、短縮名、機密性レベルを表す数値を定義する必要があります。区分およびグループはオプションです。
レベル数値は、対応するラベルに必要な機密性のレベルを表します。数値は範囲で選択します。この範囲は、セキュリティ・ポリシーでさらにレベルが必要になった場合に拡張できます。たとえば、LOW_SENSITIVITYとHIGH_SENSITIVITYというレベルを追加するには、LOW_SENSITIVITYには7300、HIGH_SENSITIVITYには7600という数値を割り当て、ポリシーにより作成されるセキュリティ・スケールに適合させることができます。通常、番号が大きいほどデータの機密性が高くなります。
コンパートメントは、ラベルが割り当てられたデータの機密性を表す領域を識別し、レベル内のより詳細なレベルを表します。コンパートメントはオプションです。
グループは、データを所有する組織またはデータにアクセスする組織を識別します。グループはデータの配布を制御する際に有用であり、組織的な変更にもタイムリに対応できます。グループはオプションです。
この手順では、レベル・コンポーネントを定義します。レベル・コンポーネントは、ACCESS_LOCATIONSポリシーで作成する必要があるSENSITIVE、CONFIDENTIAL、PUBLICラベルの名前と関係に影響します。
「Label Securityポリシーの編集」ページが表示されます。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
この手順では、「手順4: ACCESS_LOCATIONSポリシーのレベル・コンポーネントを定義する」で作成したポリシーのデータ・ラベルを作成します。データ・ラベルを作成するには、各レベルに数値タグを割り当てる必要があります。以降でポリシーを表に適用したときに、このタグの数値はセキュリティ列に格納されます。タグの数値は、ラベルの機密性とは関係ありません。この数値はポリシーのラベルを識別するためにのみ使用されます。
「データ・ラベル」ページが表示されます。
「データ・ラベルの作成」ページが表示されます。
「データ・ラベル」ページにデータ・ラベルが表示されます。
CONFレベルのデータ・ラベルを作成します。数値タグは2000と入力します。
SENSレベルのデータ・ラベルを作成します。数値タグは3000と入力します。
この段階で、「データ・ラベル」ページにCONF、PUBおよびSENSラベルが表示されます。
以降で、HR.LOCATIONS表にポリシーを適用したときに、タグの値はセキュリティ列に格納されます。この値は、ラベルの機密性には関係ありません。ポリシーのラベルを識別するために使用されるだけです。
次に、ポリシーのユーザー認可を作成します。
ACCESS_LOCATIONSポリシーを選択します。
「認可」ページが表示されます。
「ユーザーの追加: ユーザー」ページが表示されます。
「検索と選択: ユーザー」ページが表示されます。SKINGと入力して、「実行」をクリックします。
通常、データベース・ユーザー・アカウントは、たとえばCREATE USER SQL文を使用してデータベースにすでに作成されています。
その他のオプションは「データベース以外のユーザー」です。アプリケーション・ユーザーの多くは、データベース・ユーザー以外のユーザーとなります。データベース・ユーザー以外のユーザーは、データベース内には存在していません。Oracle Label Securityの命名方式に一致し、VARCHAR2(30)の長さのフィールドに適合していれば、どのユーザー名も追加できます。ただし、アプリケーションがデータベースに接続したときに、データベース・ユーザー以外のユーザーに関連するセキュリティ情報は、Oracle Databaseにより自動的には構成されません。この場合、アプリケーションは、Oracle Label Security関数を呼び出し、データベース・ユーザーではないユーザーのラベル認可を行う必要があります。
SKINGのボックスを選択して、「選択」をクリックします。「ユーザーの作成」ページにユーザーSKINGが表示されます。
ラベル認可を介してポリシーが強制されます。「権限」ページではユーザーによるポリシーのラベル認可をオーバーライド可能にするため、オプションは選択しないでください。
SKINGがHR.LOCATIONSの機密データを読み取れるようにします。
Noneに設定されていることを確認し、「次へ」をクリックします。「確認」ページが表示されます。
「確認」ページに、選択したすべての認可設定が表示されます。
KPARTNERに対して次の認可を作成し、このユーザーがHR.LOCATIONSの機密データおよびパブリック・データを読み取れるようにします。
LDORANに対して次の認可を作成します。このユーザーは、HR.LOCATIONSのパブリック・データの読取りのみが許可されます。
次に、HR.LOCATIONS表にポリシーを適用します。
ACCESS_LOCATIONSポリシーを選択します。
「適用」ページが表示されます。
「表の追加」ページが表示されます。
HR.LOCATIONSと入力します。
ACCESS_LOCATIONSのポリシーの強制のデフォルト・オプションは次のとおりです。
ACCESS_LOCATIONSポリシーがHR.LOCATIONS表に適用されます。
ACCESS_LOCATIONSポリシーをHR.LOCATIONS表に適用したら、ポリシーのラベルをLOCATIONSのOLS_COLUMNに適用します。ユーザーHR（この表の所有者）がこの操作を行うには、LOCATIONSの非表示のOLS_COLUMN列にデータ・ラベルを追加する前に、対象の場所への完全なアクセス権を持っている必要があります。
ラベル・セキュリティ管理ユーザーLBACSYSは、必要な権限をHRに付与できます。
「認可」ページが表示されます。
「ユーザーの追加」ページが表示されます。
「検索と選択」ウィンドウが表示されます。
HRのボックスを選択して、 「選択」 をクリックします。「ユーザーの作成」ページにユーザーHRが表示されます。
「権限」手順が表示されます。
ラベル、区分およびグループ・ページが表示されます。
「監査」手順が表示されます。
「確認」手順が表示されます。
この段階で、HRは他のユーザーとともに「認可」ページにリストされています。
この時点で、ユーザーHRはHR.LOCATIONS表のOLS_COLUMN列を更新して、CITY列の都市に基づいて表内の特定の行に割り当てられるデータ・ラベルを追加できます。
HRとして接続します。
CONNECT HR Enter password: password
HRとしてログインできない場合、このアカウントはロックされているか、期限が切れているため、SYSTEMとしてログインしてから、次の文を入力します。passwordは、HRアカウントに適したパスワードに置き換えます。セキュリティを考慮して、以前のリリースのOracle Databaseで使用していたパスワードと同じパスワードは再使用しないでください。「パスワードの作成要件」を参照してください。
ALTER USER HR ACCOUNT UNLOCK IDENTIFIED BY password
UPDATE文を入力して、北京、東京、シンガポールにSENSラベルを適用します。
UPDATE LOCATIONS SET ols_column = CHAR_TO_LABEL('ACCESS_LOCATIONS','SENS') WHERE UPPER(city) IN ('BEIJING', 'TOKYO', 'SINGAPORE');
UPDATE文を入力して、ミュンヘン、オックスフォード、ローマにCONFラベルを適用します。
UPDATE LOCATIONS SET ols_column = CHAR_TO_LABEL('ACCESS_LOCATIONS','CONF') WHERE UPPER(city) IN ('MUNICH', 'OXFORD', 'ROMA');
UPDATE文を入力して、残りの都市にPUBラベルを適用します。
UPDATE LOCATIONS SET ols_column = CHAR_TO_LABEL('ACCESS_LOCATIONS','PUB') WHERE ols_column IS NULL;
SELECT LABEL_TO_CHAR (OLS_COLUMN) FROM LOCATIONS;
HRからフルアクセス権を取り消します。ユーザーHRからフルアクセス権を取り消すには、「HR.LOCATIONS表に対するHR FULLポリシー権限の付与」の手順を参照してください。
ACCESS_LOCATIONSポリシーの作成は完了しました。次に、ポリシーをテストします。3人のユーザーのそれぞれとしてSQL*Plusにログインし、HR.LOCATIONS表でSELECTを実行することで、テストできます。
skingとして接続します。
CONNECT sking Enter password: password
次のコマンドは、読み取りやすいように表の列幅を書式設定します。
COL city HEADING City FORMAT a25 COL country_id HEADING Country FORMAT a11 COL Label format a10
次に、SELECT文を次のように入力します。
SELECT city, country_id, LABEL_TO_CHAR (OLS_COLUMN) AS Label FROM hr.locations ORDER BY ols_column;
ユーザーskingは、HR.LOCATIONS表の23行すべてにアクセスできます。アクセスはラベルCONFおよびSENSが付けられた行に対してのみ認可されていますが、ラベルPUBが付けられた行を読み取ることができます（ただし、書き込むことはできません）。
City Country LABEL ------------------------- ----------- ---------- Venice IT PUB Utrecht NL PUB Bern CH PUB Geneva CH PUB Sao Paulo BR PUB Stretford UK PUB Mexico City MX PUB Hiroshima JP PUB Southlake US PUB South San Francisco US PUB South Brunswick US PUB Seattle US PUB Toronto CA PUB Whitehorse CA PUB Bombay IN PUB Sydney AU PUB London UK PUB Oxford UK CONF Munich DE CONF Roma IT CONF Singapore SG SENS Tokyo JP SENS Beijing CN SENS 23 rows selected.
kpartnerとldoranで、手順1と手順2を繰り返します。ユーザーKPARTNERは、ラベルCONFおよびPUBが付けられた行にアクセスできます。
City Country LABEL ------------------------- ----------- ---------- Venice IT PUB Utrecht NL PUB Bern CH PUB Mexico City MX PUB Hiroshima JP PUB Southlake US PUB South San Francisco US PUB South Brunswick US PUB Seattle US PUB Toronto CA PUB Whitehorse CA PUB Bombay IN PUB Sydney AU PUB London UK PUB Stretford UK PUB Sao Paulo BR PUB Geneva CH PUB Oxford UK CONF Munich DE CONF Roma IT CONF 20 rows selected.
ユーザーLDORANは、ラベルPUBが付けられた行にアクセスできます。
City Country LABEL ------------------------- ----------- ---------- Venice IT PUB Hiroshima JP PUB Southlake US PUB South San Francisco US PUB South Brunswick US PUB Seattle US PUB Toronto CA PUB Whitehorse CA PUB Bombay IN PUB Sydney AU PUB London UK PUB Stretford UK PUB Sao Paulo BR PUB Geneva CH PUB Bern CH PUB Utrecht NL PUB Mexico City MX PUB 17 rows selected.
このチュートリアルで作成したコンポーネントを削除します。
SYSTEMとして接続します。
kpartnerを選択してから、「削除」をクリックします。
ldoranとskingで、手順4と手順5を繰り返します。
emp_roleロールを選択し、次に「編集」を選択します。
LABCSYSとして再度ログインします。
ACCESS%と入力して、「実行」をクリックします。
ACCESS_LOCATIONSが選択されていることを確認し、「削除」をクリックします。「確認」ページで、「はい」をクリックします。ACCESS_LOCATIONSポリシーを削除すると、HR.LOCATIONS表からOLS_COLUMN列も削除されます。
Oracle Database Vaultを使用すると、Oracle Databaseに対する管理アクセスを制限できます。これによって、内部の脅威に対する保護、コンプライアンス要件の遵守、職務分離の適用など、現在も続く、セキュリティの最も困難な問題に対処できます。
一般的に、Oracle Database管理者の主な仕事は、データベースのチューニング、アップグレードのインストール、データベースの状態の監視、検出された問題の修復などのタスクを実行することです。Oracle Databaseのデフォルトのインストールでは、データベース管理者に、ユーザーを作成し、ユーザーのデータにアクセスできる権限が付与されています。セキュリティを考慮すると、このような作業は、必要であると考えられるユーザーだけに制限する必要があります。これを職務分離と呼びます。職務を分離することで、データベース管理者は、パフォーマンスのチューニングなど、本来の専門業務に専念することができます。
Oracle Database VaultではOracle Databaseへの管理者のアクセスが制限されるため、Payment Card Industry（PCI）Data Security Standard（DSS）要件、Sarbanes-Oxley（SOX）Act、European Union（EU）Privacy Directive、Healthcare Insurance Portability and Accountability（HIPAA）Actなど、一般的なコンプライアンス要件への遵守が容易になります。これらの規制では、詐称行為、IDの盗用、財政面での不正行為および財政面での不利益をもたらす可能性のある機密情報のアクセス、開示または変更に対する強力な内部制御が必要です。
Oracle Database Vaultでは、Oracle Databaseへの管理者のアクセスを制限するために次の方法が提供されています。
SELECT、ALTER SYSTEM、データ定義言語（DDL）およびデータ操作言語（DML）文を保護できます。ルール・セットを関連付けて、コマンド・ルールをさらにカスタマイズすることができます。
これらのコンポーネントを作成するには、Oracle Database Vault Administratorを使用するか、またはそのPL/SQLパッケージを使用します。
OEスキーマには、顧客に許可しているクレジットの上限などの機密情報が格納されている様々な表があります。Order Entry表には、一般的に、クレジット・カード番号、社会保険番号などの機密情報が格納されています。Payment Card Industry（PCI）Data Security Standards（DSS）によれば、このような種類の情報は、このような情報へのアクセスが仕事上必要な人にのみ制限される必要があります。
このチュートリアルでは、OEスキーマを対象としたレルムを作成し、管理者のアクセスから保護します。ただし、ユーザーSCOTTはOE.CUSTOMERS表にアクセスする必要があるため、このユーザーがこのデータへのアクセスを続行できるようにする必要があります。
このチュートリアルでは、次の手順を実行します。
この項の内容は次のとおりです。
Oracle Database Vaultは、Oracle Databaseのデフォルトのインストールではインストールされませんが、Oracle Databaseインストール・メディアで利用できる製品に含まれています。インストールは、Oracle Universal Installerを使用し、既存のデータベースに対して行います。
SQL*PlusにSYSとしてログインし、SYSOPER権限で接続します。SQLプロンプトで、次のコマンドを入力します。
SHUTDOWN IMMEDIATE
EXIT
「インストール・タイプの選択」ウィンドウが表示されます。
ホームの詳細の指定画面が表示されます。
デフォルトでは、新しいOracleホームを作成するよう提案されるため、既存の正しいOracleホームを選択する必要があります。その後、システムが最低要件を満たしているかどうかが確認されます。次に、「使用可能な製品コンポーネント」ウィンドウが表示されます。
このオプションは、Enterprise Editionのオプションの下にあります。Oracle Label Securityもインストールする必要があるため、Oracle Universal Installerによって選択されています。「Oracle Services For Microsoft Transaction Server」も選択されていますが、不要な場合はこの選択を解除できます。次に、「次へ」をクリックします。
「サマリー」ウィンドウが表示されます。
新しい製品には、Oracle Database Vault J2EEアプリケーション、Oracle Database VaultオプションおよびOracle Label Securityが含まれます。
「インストール」をクリックした後、進行状況ウィンドウが表示されます。インストールが完了すると、「インストールの終了」ウィンドウが表示されます。
$ORACLE_HOME/binディレクトリに移動し、次のコマンドを実行してデータベース・コンソールおよびリスナーを起動します。
./emctl start dbconsole ./lsnrctl start
SQL*Plusを起動し、データベース・インスタンスを再起動します。
SQLPLUS "SYS/AS SYSOPER" Enter password: password Connected to an idle instance SQL> STARTUP
orclである場合、この名前は次のようになります。
Oracle Database Vaultをインストールした後、それをデータベースに登録し、アカウントを作成する必要があります。
dbca
一般的に、dbcaは$ORACLE_HOME/binディレクトリにあります。
または、次のコマンド・プロンプトでDatabase Configuration Assistantを起動できます。
dbca
Windowsでは一般的に、dbcaはORACLE_BASE¥ORACLE_HOME¥binディレクトリにあります。
「操作」ページが表示されます。
「データベース」ページが表示されます。
「データベース・コンテンツ」ページが表示されます。
Oracle Database Vaultがチェックされ、名前がグレーアウトされている場合は、すでに登録されています。
Oracle Database Vaultを選択すると、「Oracle Database Vault資格証明」ページが表示されます。
DBVOWNERなど）の名前とパスワード、およびDatabase Vaultアカウント・マネージャ（DBVACCTMGRなど）の名前とパスワードを指定します。「パスワードの作成要件」に示されているパスワードのガイドラインに従って、任意のセキュアなパスワードを入力します。Oracle Database Vaultには、追加のパスワード要件があります。これは、不適切なパスワードを作成しようとすると表示されます。
「接続モード」ページが表示されます。
Oracle Database Vaultが登録され、データベース・インスタンスが再起動されます。
Database Vaultアカウント・マネージャおよびOEアカウントには、Database Controlを使用するためにSELECT ANY DICTIONARY権限が必要です。
SYSユーザーとしてDatabase Controlにログインします。「ログイン」ページでSYSとSYSに割り当てられたパスワードを入力します。「接続モード」をSYSDBAに設定します。「ログイン」を選択してログインします。Database Controlの起動方法については、『Oracle Database 2日でデータベース管理者』を参照してください。
「ユーザー」ページが表示されます。
DBVACCTMGR）を選択します。DBVACCTMGRを簡単に検索するには、「オブジェクト名」フィールドにDBVと入力し、「実行」をクリックします。
DBVACCTMGRが選択された状態で、「編集」をクリックします。「ユーザーの編集」ページが表示されます。
「システム権限の変更」ページが表示されます。
SELECT ANY DICTIONARYを選択し、「移動」をクリックして「選択したシステム権限」リストに移動します。次に「OK」をクリックします。
OEにもSELECT ANY DICTIONARY権限を付与します。
後でチュートリアルをテストするときに、ユーザーSCOTTはOE.CUSTOMERS表からの選択を行う必要があります。まず、SCOTTアカウントが有効であることを確認する必要があります。
Database Controlを起動する手順については、『Oracle Database 2日でデータベース管理者』を参照してください。
Oracle Database Vaultをインストールした後は、管理アカウントを使用してユーザー・アカウントを作成または有効化することはできません。これは、Oracle Database Vaultがデフォルトの状態のままでも、管理アカウントに対して職務分離の方針が適用されるためです。この時点から、ユーザー・アカウントを管理するには、Oracle Database Vaultアカウント・マネージャのアカウントを使用する必要があります。
だたし、管理ユーザーには、その業務に必要な権限は付与されたままです。たとえば、システム権限と多数のPL/SQLパッケージを所有するユーザーSYSは、引き続きこれらの権限を他のユーザーに付与できます。
「ユーザー」ページが表示されます。
「ユーザーの編集」ページが表示されます。
SCOTTアカウントのパスワードのステータスが期限切れである場合は、新しいパスワードを入力します。「パスワードの作成要件」に示されているパスワードのガイドラインに従って、任意のセキュアなパスワードを入力します。
OEとしてログインします。Database Controlを起動する手順については、『Oracle Database 2日でデータベース管理者』を参照してください。
「ユーザー」ページが表示されます。
「ユーザーの編集」ページが表示されます。
「オブジェクト権限」サブページが表示されます。
「表オブジェクト権限の追加」ページが表示されます。
OE.CUSTOMERSと入力するか、または懐中電灯アイコンを使用してこの表を検索します。
「ユーザーの編集」ページが表示されます。
この段階では、ユーザーSYSおよびSCOTTの両者が、OE.CUSTOMERS表からの選択を行うことができます。これは、SYSは管理権限を所有し、SCOTTはユーザーOEによって付与された明示的なSELECT権限を所有しているためです。
SYSDBA権限を使用してユーザーSYSとして接続します。
SQLPLUS "SYS/AS SYSDBA" Enter password: password Connected.
OE.CUSTOMERS表から選択を行います。
SELECT COUNT(*) FROM OE.CUSTOMERS;
次の出力が表示されます。
COUNT(*) -------- 319
SCOTTとして接続し、同じSELECT文を実行します。
CONNECT SCOTT Enter password: password Connected. SELECT COUNT(*) FROM OE.CUSTOMERS;
次の出力が表示されます。
COUNT(*) -------- 319
OE.CUSTOMER表への管理アクセスを制限するには、OEスキーマに対するレルムを作成します。
ブラウザに、次のURLを入力します。
https://host_name:port/dva
host_nameはOracle Database Vaultをインストールしたサーバーの名前に、portはOracle Enterprise ManagerコンソールのHTTPSポート番号に置き換えます。ほとんどの場合、サーバーの名前とポート番号は、Database Controlで使用しているものと同じです。
Database Vault Administratorを起動できない場合は、これを手動でデプロイする必要があります。詳細は、『Oracle Database Vault管理者ガイド』を参照してください。
DV_OWNERアカウントの名前を入力します（DBVOWNERなど）。
myserver.us.example.comなど）。
orclなど）またはサービス（myserver.us.example.comなど）を入力します。
データベース・インスタンスの「管理」ページが表示されます。
「レルム」ページが表示されます。
「レルムの作成」ページが表示されます。
「レルム」ページが表示され、レルムとしてOEが示されます。ただし、保護されたオブジェクトまたは認可されたユーザーはまだ存在しません。
「レルムの編集」ページが表示されます。
「レルム・セキュア・オブジェクトの作成」ページが表示されます。
OEは、OEスキーマを所有するアカウントです。OEユーザーを選択すると、このアカウントでOEスキーマ表を引き続きメンテナンスできます。
OEスキーマ内のすべての表を指定するために%を入力し、「OK」をクリックします。「レルムの編集」ページが表示されます。
「レルム認可の作成」ページが表示されます。
OEを選択し、「認可タイプ」を「所有者」に設定します。その後で、「認可ルール・セット」を<未選択>に設定します。これによって、OEスキーマ内のオブジェクトへのアクセスを管理するOEユーザーが認可されます。所有者として、OEユーザーは、レルムで保護されたデータベースのロールの付与または取消し、OE Protectionsレルムで保護されたオブジェクトのアクセス、操作および作成を実行できます。
「認可ルール・セット」リストを使用すると、レルムが有効になる時間など、アクセスをさらに制御するルールを選択できます。
OEスキーマを保護するレルムが作成され、テストを実行できるようになりました。データベース・セッションを再び開始する必要はありません。これは、Oracle Database Vaultで定義した保護は即時に有効になるためです。
SYSDBA権限を使用してユーザーSYSとしてSQL*Plusに接続します。
CONNECT SYS/AS SYSDBA Enter password: password Connected.
OE.CUSTOMERS表からの選択を試行します。
SELECT COUNT(*) FROM OE.CUSTOMERS;
次の出力が表示されます。
ERROR at line 1: ORA-01031: insufficient privileges
OE Protectionsレルムによって、管理ユーザーのOE.CUSTOMERS表へのアクセスが制限されています。スキーマ全体を保護するようにOE Protectionsレルムを定義したため、管理ユーザーはOE内の他の表にもアクセスできません。
SCOTTとして接続します。
CONNECT SCOTT Enter password: password Connected.
OE.CUSTOMERS表からの選択を試行します。
SELECT COUNT(*) FROM OE.CUSTOMERS;
次の出力が表示されます。
COUNT(*) ---------- 319
OE ProtectionsレルムはユーザーSCOTTには適用されません。これは、ユーザーOEによって、OE.CUSTOMERS表に対するSELECT権限がこのユーザーに明示的に付与されているためです。Oracle Database Vaultによって、必要な保護が設定されますが、ユーザーが定義した明示的な権限が上書きされることはありません。SCOTTは、引き続きこの表を問い合せることができます。
EXIT
このチュートリアルの終了後、使用したデータ構造が不要な場合は削除できます。
Database Controlを起動する手順については、『Oracle Database 2日でデータベース管理者』を参照してください。
OEユーザーとしてログインします。
「ユーザー」ページが表示されます。
「ユーザーの編集」ページが表示されます。
OE.CUSTOMERS表のSELECTオブジェクト権限を選択し、「削除」をクリックします。その後で、「適用」をクリックします。
「ログイン」ページが表示されます。
SYSとしてログインし、SYSDBA権限を使用して接続します。Database Controlのホームページが表示されます。
「ユーザー」ページが表示されます。
「ユーザーの編集」ページが表示されます。
「システム権限の変更」ページが表示されます。
Database Vault Administratorの起動方法については、「手順4: OE.CUSTOMERS表を保護するためにレルムを作成する」の手順1を参照してください。
DV_OWNERアカウントの名前（DBVOWNERなど）を使用してログインします。「管理」ページが表示されます。
「レルム」ページが表示されます。
|
 Copyright © 2007, 2008 Oracle Corporation. All Rights Reserved. |
|