11

私は最近、何人かの同僚を助けるために Perl とシェル スクリプトのスキルを磨かなければなりませんでした。問題の同僚は、大規模な Oracle データベース バックエンドを使用して内部アプリケーションからいくつかのレポートを提供する任務を負っていますが、これを行うスキルがありません。私にそんなスキルがあるのか​​と疑問に思う人もいるかもしれませんが(笑)、そう思っている人も多いようです。

だから私の質問に-データベースからレポートを抽出するために、私のスクリプトは明らかに接続してクエリを実行する必要があります。これまでのところ、データベースのユーザー名とパスワードを保存する場所の適切な解決策を思い付くことができなかったため、現在はスクリプトにプレーンテキストとして保存されています。

おそらくCPANモジュールとして、他の誰かがすでに書いているこれに対する良い解決策はありますか? または、ファイルシステムの別の場所に隠されている完全に別のファイルにユーザー/パスワードの組み合わせを保持するなど、他に行うべきことがありますか? それとも、システム全体の grep を使用してスクリプトから引き出されるのを避けるために、単純に暗号化したままにしておく必要がありますか?

編集: Oracle データベースは HP-UX サーバー上にあります。
アプリケーション サーバー (シェル スクリプトを実行) は Solaris です。
スクリプトを自分だけが所有するように設定することはできません。複数のサポート担当者がアクセスできるサービス アカウントがスクリプトを所有する必要があります。
スクリプトは、cron ジョブとして実行することを目的としています。
私は公開鍵認証を使いたいと思っていますが、Oracleでそれを機能させる方法を知りません-そのような方法があれば-教えてください!

4

13 に答える 13

7

私見のベストプラクティスは、シェル/Perlスクリプトにパスワードを保持しないことです。それが公開鍵認証です。

于 2008-09-17T06:55:10.030 に答える
5

スクリプトがサーバーからリモートで実行されている場合。

  1. レポートを表示する
  2. ログインしているユーザーに、レポート ビューで選択するためのアクセス権のみを付与します。
  3. パスワードを保存するだけです。

そうすれば、ユーザーができることは、レポートのデータを選択することだけです。たまたまパスワードを入手したとしても、そのパスワードでできることは限られています。

于 2008-09-17T07:07:16.693 に答える
4

個人的には、アプリケーションとは別に配布される構成ファイルにパスワードを保持し、特定のマシン/環境に変更できます。シェル スクリプトでは、これらをメイン スクリプト内で入手できます。

ただし、Perl にはさまざまなアプローチがあります。コマンド ライン オプションについてGetopt::Longを調べたり (さらにGetopt::ArgvFileを使用して単純な構成ファイルに格納することもできます)、あるいはConfig::IniFilesのようなものを調べて、その背後にあるもう少し強力なものを探してください。これらは私が通常使用する 2 つのタイプですが、他にも使用可能な構成ファイル モジュールがあります。

于 2008-09-17T12:58:16.257 に答える
1

kshとbashにタグを付けたので、Linuxを想定します。

問題のほとんどは、ユーザーがスクリプトを読んで、ファイルの非表示/暗号化に使用した方法を見つけることができれば、同じことを手動で実行できることです。

より良い方法は、次のことを行うことです。

  1. スクリプトを作成して、自分だけが表示/読み取り/開くことができるようにします。chmod700それ。パスワードをハードコードします。
  2. ユーザーが実行可能でsudoを実行する「ランチャー」スクリプトを用意します。

このようにして、ユーザーはランチャースクリプトを確認し、それを調べて、コマンドラインが1つしかないことを確認できます。彼らはそれを実行でき、それは機能しますが、sudoされたスクリプトのソースを読み取る権限がありません。

于 2008-09-17T06:57:09.557 に答える
1

パスワードを保存するには、最初にスクリプト自体にハードコードされたキーを使用し、オプションでファイルに保存されたキーを使用して 2 段階の暗号化ルーチンを実行できます (ファイル許可を使用してアクセスを制限するように設定されています)。

特定の状況では、キー ファイル (+ スクリプトからのキー) を使用できます。または、状況の要件がそれほど大きくない場合は、スクリプトにハードコーディングされたキーを使用して暗号化を使用できます。どちらの場合も、パスワードは構成ファイルで暗号化されます。

どうにかしてクリアテキストのパスワードを解読して取得できるようにする必要があるため、完全な解決策はありません...そして、あなたがそれを行うことができれば、他の誰かが正しい情報を持っていればそれを行うこともできます.

特に、(exe ではなく) perl スクリプトを提供する状況では、暗号化 (およびハードコードされたキー) を行う方法を簡単に確認できます...そのため、キーファイルを使用するオプションを許可する必要があります (ファイルシステムのアクセス許可によって保護されている必要があります)。

実装方法の実用的な例はこちら

于 2008-09-17T16:22:55.767 に答える
1

実行している Oracle のバージョンがわかりません。古いバージョンの Oracle (9i Advanced Security より前) では、一部の DBAが trueCREATE USER OPS$SCOTT IDENTIFIED BY EXTERNALLYに設定REMOTE_OS_AUTHENTします。

これは、リモートの Sun マシンがユーザーを SCOTT として認証し、Oracle DB がその認証を受け入れることを意味します。

これは悪い考えです。

SCOTT のローカル ユーザーで任意の Windows XP をイメージできるため、パスワードなしで DB にログインできます。

残念ながら、Oracle 9i DB について知っている唯一のオプションは、ユーザー名/パスワードをスクリプトまたはクライアント マシンからアクセスできる場所に保存しないことです。

どのようなソリューションであっても、コミットする前にOracle のProject Lockdownを確認する価値があります。

于 2008-09-17T09:19:50.043 に答える
1

良い解決策はありません。パスワードを少し難読化することはできますが、保護することはできません。

DBセットアップを制御できる場合は、パスワードなしで名前付きパイプ(少なくともmysqlがサポート)で接続を試み、OSに権限を処理させることができます。

権限が制限されたファイルに資格情報を保存することもできます。

于 2008-09-17T06:53:38.363 に答える
0

SolarisサーバーからANTを使用してSQLコードをMSSQL(実際にはそのMSSQLサーバー上の任意のデータベースに展開するため、役割はSysAdminである必要があります)にSQLコードを展開する開発者と同様の問題が発生しました。繰り返しになりますが、ユーザー名とパスワードをANT build.xmlファイルに保存したくなかったので、私の解決策は理想的ではないとわかっていますが、次のようになります。

  1. ユーザー名とパスワードの名前と値のペアをプレーンテキストファイルに保存します
  2. (Solarisの場合)ファイルを暗号化し、特定の管理者だけが知っているパスフレーズを使用する
  3. 暗号化されたファイルのみをSolarisシステムに残します
  4. ANT build.xmlは、sudo復号化を実行し、管理者が入力したパスフレーズの入力を求めます
  5. ANTは、SQL文字列の変数としてユーザー名とパスワードをロードする復号化されたファイルをソースします
  6. ANTはすぐに平文ファイルを削除しました
  7. ANTはコードをデプロイして終了します

これはすべてほんの数秒で発生し、SQLのユーザー名とパスワードがサーバー上で目に見える形でアクセスされることはありません。コードは本番環境で許可された管理者によってデプロイされるため、開発者はコードにコードを含める必要はありません。

私はそれがより良いかもしれないと確信しています、しかし...

JB

于 2008-09-17T11:15:07.877 に答える
0

UNIXでは、これらのスクリプトを常にsetuidにして、ユーザーとパスワードの情報を厳重に保護されたファイルに保存します(ディレクトリツリー全体は通常のユーザーには読み取り/検索できず、ファイル自体はスクリプトの所有者のみが読み取り可能です) 。

于 2008-09-17T06:57:56.123 に答える
0

それらを別のファイルに保存し、簡単に暗号化して、必要なテーブルへの読み取り専用アクセス権を持つ別のユーザーをデータベースに作成します。ファイルが読み取られたと思われる場合は、そのユーザーのみへのアクセスを遮断できます。

凝ったものにしたい場合は、SUIDプログラムが/ proc // exeとcmdline(Linuxの場合)をチェックしてから、ユーザー名を解放することができます。

于 2008-09-17T07:01:32.700 に答える
0

Windows では、クリア テキストのパスワードを含むフォルダーとその中にファイルを作成します。スケジュールされたジョブ (スクリプトまたはバッチ) を実行するユーザーを、このフォルダーとファイルへの読み取り/書き込みアクセス権を持つ唯一のユーザーとして設定します。(管理者も削除)。他のすべてのスクリプトに、この制限付きファイルから平文のパスワードを読み取るコードを追加します。

これで十分な場合があります。

キーワード: パスワードのハードコーディング

于 2009-07-14T10:21:23.800 に答える
0

このスレッドを今まで見たことがなかったのは残念です。とても面白そうです。将来スレッドに出くわす人のために、2 セントを追加します。

DBサーバー自体でOS認証を使用することをお勧めします-REMOTE_OS_AUTHENTはまだFALSEです。

別のマシンからスクリプトを呼び出す場合は、フレーズのない SSH キーをセットアップし、SSH を使用してアクセスします。次に、SQL の結果を呼び出し元のマシンにパイプで戻すことができ、この情報をさらに処理できます。

これを行うと、パスワードをどこにでもコーディングする必要がなくなります。もちろん、悪意のある管理者がフレーズレス キーを乗っ取って使用した場合、DB ホストのユーザー アカウントにもアクセスでき、OS 認証済み DB ユーザーが実行できる操作を行うことができます。これを軽減するには、その OS ユーザーのデータベース権限を最小限に抑えることができます。たとえば、「読み取り専用」としましょう。

インゴ

于 2009-06-12T21:31:38.803 に答える