OS認証がOracleデータベースのセキュリティが低いと見なされるのはなぜですか？
オラクルは Oracle Database Security Guide に従ってOS認証を非推奨にしています。
REMOTE_OS_AUTHENTパラメータはOracle Database 11gリリース1（11.1）で廃止され、下位互換性のためにのみ保持されていることに注意してください。
さらに、ほとんどのセキュリティ情報とツールは OS（外部）認証 をセキュリティの問題と見なしています。なぜそうなのか理解しようとしています。 OS認証の利点は次のとおりです。
- OS認証がない場合、アプリケーションは、独自のセキュリティモデルと脆弱性を持つさまざまなアプリケーションにパスワードを保存する必要があります。
- ドメイン認証は、安全でないとデータベースへのアクセスが遅くなるだけで防止できないため、すでに安全である必要があります。
- 1つのドメインパスワードを覚えるだけでよいユーザーは、接続する必要があるさまざまなデータベースの数が増えるにつれて、より安全性の低いデータベースパスワードを作成するよりも、より安全なドメインパスワードを簡単に作成できます。
次のシナリオを検討してください。
- 外部認証を使用してOracleサーバーに
gaiusという名前のUnixユーザーがいるため、Oracleではops$gaiusという対応するユーザーがいます。シェルにログインすると、Oracleスキーマに直接ログインすることもできます。また、cronジョブには、スクリプトに埋め込まれたパスワードも必要ありません。 - LANが100％安全でクライアントが信頼できるという前提で、リモートOS認証が許可されます（
rlogin/rshが通常許可されていたのと同じ） - 攻撃者は何らかの手段でラップトップをLANに接続し、私がそこで作業していることを知って、ラップトップに
gaiusというローカルユーザーを作成し、そのユーザーとしてSQL * Plusを実行します。 - Oracleは（
V$SESSIONのOSUSERがgaiusであると認識し、そのリモートユーザーをops$gaiusとしてログインします。
それは笑えるほど簡単になりすますだけでなく、私の皮肉屋の帽子をかぶって、オラクルはあなたに彼らを売ることでこれ以上のお金を稼ぐことができません ファンシーなシングルサインオン製品 ...ちなみにdoesは、OSレベルの認証の利点として挙げたすべてのポイントを満たします。 1つのパスワードよりも2つのパスワードのほうが完全に偽です。ほとんどの人はとにかくそれらを同じに設定します（これを防ぐためのOracleのメカニズムはありません）。
一般的な原則として、攻撃者が物理的にアクセスできる場合、ソフトウェアで防御することは非常に困難です。そして、決してクライアントを信頼しないでください。
単一障害点が増加し、データのリスク面が拡大します。
システムにアクセスする攻撃者は、OS認証を使用して、データベースにアクセスできます。データベースへのより安全なアクセスを要求することにより、潜在的な攻撃者は、ユーザーではなくrootまたはOracleアクセスを取得するために、侵害されたシステムでの権限をエスカレートする必要があります。
この問題は、データベースへの外部アクセスの機能です。外部アクセスがなく、マシンが完全に保護されている場合、権限の問題は疑わしいものです。ただし、開発者がアクセスできる場合、OSレベルのユーザー権限により、潜在的なセキュリティ災害の範囲が拡大します。
すべてのインスタンスにOSレベルのアカウントを作成する必要なしに、セキュリティ違反の範囲を制限し、すべてのユーザー、アプリケーション、またはクライアントに必要なアクセス権を与えるために multitier access の使用を検討してください。
Gaiusはすでにremoteオペレーティングシステム認証（ローカルマシンのユーザーがデータベースを指定せずにデータベースにアクセスできるようにするVanillaオペレーティングシステム認証とは対照的に）を指摘しています。別のパスワード）は比較的安全ではありません。
Oracleがこの方向に向かっているのは、リモートオペレーティングシステムで認証されたユーザーではなく エンタープライズユーザー （または本格的なID管理スイート）を使用することを人々に勧めたいからです。エンタープライズユーザーには、リモートオペレーティングシステムで認証されたユーザーと同じ利点がありますが、Oracleは実際にはユーザーを認証するためにActive Directoryサーバーにアクセスします。セキュリティチェックをクライアントマシンに任せることなく、同じシングルサインオンのメリットを得られます。
具体的には、identスタイルの認証を示していますが、データベースや他のログインをOSのログインに結び付ける他の方法も同様に悪いことを指摘しておきます。 （ローカルパスワードファイル、LDAP、または資格情報の実際の保存用の何か）
データベース（またはWebサーバー、または認証を行うもの）へのリモート接続を許可する場合、一部のOSは、アカウントのブルートフォースのブルートフォースを困難にするように設定されている可能性のあるルールを無視します（たとえば、失敗した試行の送信元であるIPのブロック、ロック一定数の異常後の期間のユーザーなど）。通常、これらのルールはsshdに結び付けられ、not認証システム全体として結び付けられます。
したがって、誰かがデータベース/ webserver /にリモートで接続できるようになった場合、データベースは同じメカニズムを使用して試行を遅らせる傾向がないため、パスワードをブルートフォースにして、必要な資格情報を見つけたらsshでログインすることができます。