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

情報が現在世界を動かしていることは秘密ではありません。企業が知的財産を管理し、各従業員が必要な情報を簡単に入手できれば、企業は成長を期待できます。データに混乱があると、チームスピリットにもかかわらず企業は失敗します。

この記事では、データベースのセキュリティの基本とOracleでの情報保護の例について説明します。実際、この記事で検討するデータベース内の情報を保護するための理論的な基本は、他のデータベースを使用する人々にも役立ちます。

アクセス許可

私が働いていたほとんどの企業では、すべての管理者と開発者がデータベースに完全にアクセスでき、IT部門の従業員は神であり、彼らがやりたいことは何でもできました。なぜそれが起こるのですか？これには2つの理由があります：

1. 1つの部門で働いている間、従業員は毎日8時間会い、友達になることができます。どうすればアクセスを許可できませんか？友情は一つのことですが、ビジネスはビジネスです。
2. アクセス権を付与したり、構成を変更したりするには、いくつかの権限が必要になる場合があります。管理者は、プログラマーが設定をより適切に構成すると考えることがあります。したがって、これらはプログラマーに不要なアクセス権を提供します。代わりに、プログラマーは管理に関与してはならず、これに対するいかなる権利も持ってはなりません。

私の経験では、2番目の問題は非常に一般的であるため、詳細に分析します。

データベース用のプログラムを開発する場合、プログラマーはスーパーユーザーのパスワードを知っているか、単にデータベース管理者権限を持っています。これは不要であり、絶対に安全ではありません。データベース管理者のみが完全な権限を持っている必要があります。部門の責任者、ディレクター、親友でさえ、特権が少なくなる可能性があります。

たとえば、プログラムを開発するときは、作業テーブルを格納するOracleデータベースのスキーマ所有者権限があれば十分です。これらの権限は、新しいテーブル、パッケージ、インデックス、およびその他のオブジェクトを作成するだけでなく、スキーマオブジェクトへのアクセス権を他のユーザーに付与するのに十分です。フルタイムの仕事にはシステム権限は必要ありません。

フルタイムでデータベース管理者がいない場合、それは非常に悪いことです。データベースのパフォーマンス、最適化、およびセキュリティの責任者がいる場合に適しています。少なくとも、これに責任を持ち、独占的な権利を持つプログラマーを1人任命する必要があります。

統計によると、会社の従業員は最も頻繁にデータ損失を引き起こします。それでも、この事実にもかかわらず、ほとんどの企業はこのスレッドを無視し続けており、無料アクセスでディスクに保存されているさまざまなデータベースが地下鉄でも販売されています。

ユーザーと役割

データベースにアクセス権を付与するには、ユーザーとロールの2つのオブジェクトタイプがあります。ロールは、同様の権限を持っている必要があるユーザーを組み合わせるいくつかのグループです。たとえば、すべての会計士が財務書類へのアクセスを要求する場合があります。各会計士に権利を付与することを防ぐために、必要なアクセス権を持つ役割にそれらを組み合わせることができます。

ご覧のとおり、ロールの原則はWindowsオペレーティングシステムのグループに似ています。それでも、いくつかの違いがあります。理由がないわけではありませんが、ユーザー、グループ、ロールなどの3つのオブジェクトタイプすべてをデータベースに実装できます。ただし、ほとんどのデータベースにはユーザーとロールのみが実装されています。ロールによって付与された権限を取得する各ユーザーが、タスクを解決するために実際に必要なデータにアクセスできるように、これらすべてのオブジェクトを管理および監視する必要があります。ファイアウォールのルールとしてアクセス権を使用する必要があります。これらの権限を使用すると、同じ問題を解決できます。つまり、ユーザーが特定のタスクのみを実行できるようにし、損失や破損の可能性を防ぐことができます。

ロールの助けを借りて、アクセスを制御したり、アクセス許可を提供したり、ユーザーのグループ全体をブロックしたりするのは非常に便利です。一方の役割をもう一方の役割に含めることができるため、そのアクセス権を継承できます。したがって、権利の階層構造を作成できます。

企業データベースへのアクセス権を持つすべての従業員は、最小限の権限を持つ単一の役割に含めることができます。ここで、追加の権限、特定のテーブルへのアクセスが必要な場合は、ユーザーを他の役割に追加するか（グループが同じアクセスを必要とする場合）、特定のアカウントに権限を付与する必要があります。

プログラムでは、テーブルへのアクセスを制御するために、データセットを開こうとするたびに結果のエラーをチェックすることができます。アクセスエラーが発生した場合、指定されたテーブルへのアクセスはユーザーに対してブロックされます。したがって、クライアントアプリケーションへのアクセス権を実装する必要はありません。ただし、これを実装したい場合は、害はありません。少なくとも、これには重要なことは何もありません。逆の効果があるようです。

セキュリティ監査

各ユーザーがデータベース内の独自のアカウントで作業している場合は、user変数を呼び出して、現在のユーザーを判別できます。例：

SELECT user from dual

このクエリは、サーバーへの接続が開かれるユーザー名を返します。複数の人が1つの名前を使用してログインできる場合、このクエリは両方に同じ名前を返すため、監査には役立ちません。特に、ロックアウト制御がサーバーレベルで発生する場合。

複数のユーザーが同じユーザー名を使用してログインできる場合、アカウントにログインしたユーザーを特定するのは複雑ですが、それでも可能です。次のクエリを使用すると、セッションの詳細情報を取得できます。

select s.user#, s.username, s.osuser, s.terminal, s.program
from sys.v_$session s
WHERE username=user

ご覧のとおり、クエリはデータベースに接続されているユーザー名、オペレーティングシステムの名前、ターミナルのユーザー名、およびプログラムを返しました。

ここでは、sysシステムスキーマからv_$sessionビューにアクセスできます。このビューは、サーバーへの接続に関する情報を返します。 WHERE句では、出力を現在のユーザーのみに制限します。その結果、クエリは、ユーザーID、名前、オペレーティングシステムの名前、端末、および接続が確立されたプログラムを返します。

ユーザー名と端末名がわかれば、確実にユーザーを特定できます。現在のユーザーが追加された役割を知るには、次のクエリを実行できます。

SELECT GRANTED_ROLE 
FROM dba_role_privs 
WHERE grantee=user

アカウントのセキュリティ

デフォルトのパスワードがあってはならないとは言いません。一部のデータベース、たとえばMySQLは、インストール後に単純でよく知られたシステムパスワードを作成すると、間違った動作をします。また、パスワードが複雑であるべきだとも言いません。このルールはすべてのIT分野に適用され、初心者ユーザーにも知っておく必要があります。データベースの問題について話します。

私の経験では、企業プログラムを開発するとき、開発者は同じアカウントを使用してデータベースにアクセスします。このアカウントのパラメータはプログラムに直接登録されますが、経理、倉庫、人事部門などの特定のモジュールへのアクセスはプログラム方式で実装されます。一方では、この方法は便利です。プログラムは管理者権限でデータベースに接続でき、テーブルへの役割とアクセス権を管理する必要がないためです。一方、この方法は安全とは言えません。ユーザーのレベルは高まっており、会社の従業員の友人はセキュリティとハッキングの分野で教育を受けることができます。プログラムがデータベースに接続するための名前とパスワードを知った後、通常のユーザーはあなたが望むよりも多くの機会を得ることができます。

SQL言語は、秘密で複雑な言語ではありません。データベース内の任意のデータを簡単に表示できるプログラムはたくさんあります。ユーザー名とパスワードを使用すると、誰でもすべてのデータを盗むことができます。したがって、ディスクを販売するすべての屋台で販売されます。

ユーザー名とパスワードをプログラムに保存しないでください。プログラムへのアクセスも、サードパーティに制限され、不可能である必要があります。両方のログインを1つに結合することは非常に論理的です。組織内の各ユーザーに必要な最小限の権限で、データベースサーバー上に個別のアカウントを作成する必要があります。これらの名前とパスワードは、プログラムにログインするときに使用する必要があります。一般的で非常に効果的なロジックを使用できます。入力したデータを使用してデータベースにログインできる場合は、アクセスが許可されます。そうでない場合は、プログラムを中止する必要があります。データベース認証を使用したため、このプロセスは単純で効果的です。

ユーザーが同じ名前の2台の異なるコンピューターから同時に作業していないことを確認するには、次のクエリを実行できます。

select s.username, s.terminal, count(*)
from sys.v_$session s
WHERE username=user
HAVING count(*)>1
GROUP BY s.username, s.terminal

実際、レコードを返さないようにする必要があります。

ビュー

ビューは、データ構造からスイッチを切り、同時に追加レベルの保護を構築するための非常に便利な方法です。ビューが生産性にマイナスの影響を与えることは事実ですが、セキュリティにはプラスの影響があります。独自のアクセス権を付与できますが、データの取得元のテーブルにはこのアカウントからアクセスできないままにすることができます。

ビューを使用する方がよいのはいつですか。まず、それらの欠点を定義しましょう。ビューは、データを取得するためのSELECTステートメントです。 1つと複数のテーブルの両方にアクセスできます。ビューからデータを選択するだけで、パフォーマンスが低下することはありません。ただし、他のクエリでビューを使用してデータを選択し、テーブルを参照することはできます。例：

SELECT list of fields
FROM view, table_1, table_2
WHERE some parameters

この場合、クエリはビューと2つのテーブルからデータをフェッチします。さらに、すべてのオブジェクト間の関係を表示したり、追加の条件を設定したりできます。

それでは、データベースオプティマイザがクエリを認識しているところを見てみましょう。

SELECT list of fields
FROM (SELECT ...), table1, table2
WHERE some parameters

この場合、ビューを構成する括弧内の抽象SELECTステートメントにビューを置き換えました。サーバーはサブクエリを含むクエリを認識していることがわかりました。サブクエリが静的な値ではなく動的なデータを返す場合、このデータの選択は、サブクエリなしで同じクエリを記述した場合よりも遅くなります。

データセキュリティ

特別な必要がない限り、オブジェクトへのフルアクセスを許可しないでください。私は常に、SELECTステートメントでデータを選択できるようにするためだけに権利を提供し始めます。ユーザーが本当に新しいレコードを挿入する必要があり、割り当てられたタスクを実行できない場合は、この場合、指定されたテーブルのINSERTステートメントにアクセス許可を追加します。

データの最も危険な操作は、変更と削除、つまりそれぞれUPDATEとDELETEです。これらの権利を慎重に付与する必要があります。データを変更または削除できることを確認してください。この場合のみ、適切な権限を選択してください。一部のテーブルは、本質的にのみ拡張されています。

データが頻繁に影響を受けることを確認する必要があります。たとえば、従業員のテーブルを拡張および変更できますが、単一のレコードを削除しないでください。削除は、従業員の作業、レポート、およびデータの整合性の背景に影響を与える可能性があります。人事担当者が誤ってレコードを追加して削除したい場合は、引き続き可能です。ただし、このようなケースはまれであり、データベース管理者がエラーを修正できます。誰も過労を望んでおらず、許可を与える方が簡単であることを理解していますが、セキュリティの方が価値があります。

権限の付与は、GRANT演算子を使用して実行されます。一般的に、次のようになります。

ユーザーまたはロールにONオブジェクトへの権限を付与するものを付与する

たとえば、次のクエリは、TestTableテーブルを挿入して表示する権利をUser1に付与します。

GRANT Select, Insert ON TestTable TO User1

外部キー

多くのユーザーは、外部結合がある場合、通常、データの削除を許可しないため、外部キーを恐れています。カスケード削除が確立されていれば、問題は簡単に解決できます。ただし、ほとんどの専門家はこの可能性を嫌います。 1つのばかげたアクションは、確認要求なしで非常に重要なデータを破壊する可能性があります。リンクされたデータは、ユーザーがデータを削除できることを意識的に確認した場合にのみ、明示的に削除する必要があります。

外部キーを恐れないでください。これらは、データベースサーバーからのデータの整合性を制御するための便利な方法を提供します。したがって、これは決して害のないセキュリティです。削除に問題があるかもしれないという事実はただの利益です。データを永久に失うのではなく、削除しない方がよいでしょう。外部キーとインデックスは、パフォーマンスを低下させません。これは、データを削除したり、別のテーブルでデータが接続されているキーフィールドを変更したりするときの小さなチェックです。

バックアップ

バックアップは、最初のデータ損失の前に無視するセキュリティ要因の1つでもあります。しかし、個人的には、メインのものに含めていただろう。データの損失は、ハッカーや不適切なユーザーだけでなく、機器の誤動作によっても発生する可能性があります。機器の障害はデータベースの損失につながる可能性があり、その復元には数時間または数日かかる場合があります。

最も効果的なバックアップポリシーを事前に作成する必要があります。それはどういう意味ですか？データの損失によって引き起こされ、作業能力が回復するまでのダウンタイムは最小限に抑える必要があります。データの損失も最小限に抑え、バックアップがユーザーの作業に影響を与えないようにする必要があります。お金と機会がある場合は、RAID、クラスター、さらにはデータレプリケーションなどのシステムを使用することをお勧めします。

バックアップとリカバリは、別個の興味深いトピックです。ここでは触れられませんでしたが、詳しくは検討しません。

概要

特にOracleのセキュリティの基本について検討しました。データベースによって提供される保護は1レベルのみであり、保護はマルチレベルである必要があることを忘れないでください。明確な心で少し眠るには、ウイルス対策、スパイウェア対策、VPN、IDSなどを含む、ネットワーク、サーバー、およびすべてのコンピューターにセキュリティ機能全体を実装する必要があります。保護のレベルが高いほど、より多くのそれらを克服するのは難しいでしょう。

明確なセキュリティポリシーと管理が必要です。従業員が退職すると、そのアカウントは削除されます。ユーザーが同じパスワードで作業している場合、またはグループパスワードを使用してタスクを実行している場合は、これらすべてのパスワードを変更する必要があります。たとえば、管理者が退職し、すべての管理者が同じアカウントを使用している場合は、パスワードを変更する必要があります。

セキュリティが必要です。ハッカーだけでなく、経験の浅いためにデータを破壊する可能性のある「初心者」ユーザーからも身を守る必要があります。優れたセキュリティポリシーはそのようなケースを防ぐのに役立ち、この可能性を排除することはできません。データを復元して不要なダウンタイムを取得するために多くの時間を失うよりも、経験の浅いデータを事前に保護する機能を提供することをお勧めします。

また読む：

データベースアクセス許可の設定