web-dev-qa-db-ja.com

Webアプリの展開のためにWebサーバーの資格情報を保存するためのベストプラクティスは何ですか？

私は探していました weblogic mavenプラグインのOracleドキュメントで

その中に、アクセスするためのweblogicユーザー名とパスワードをpom.xmlに格納します。

ただ疑問に思う、これはひどい考えではありませんか？これをどのように処理する必要がありますか？

 <plugin> 
      <groupId>com.Oracle.weblogic</groupId> 
      <artifactId>weblogic-maven-plugin</artifactId> 
      <version>10.3.4</version> 
      <configuration> 
          <adminurl>t3://localhost:7001</adminurl>
          <user>weblogic</user> 
          <password>weblogic123</password> 
          <upload>true</upload> 
          <action>deploy</action> 
          <remote>false</remote> 
          <verbose>true</verbose> 
<source>${project.build.directory}/${project.build.finalName}.${project.packaging}</source> 
         <name>${project.build.finalName}</name> 
      </configuration> 

      <executions> 
         <execution> 
            <phase>install</phase> 
              <goals> 
                <goal>deploy</goal> 
              </goals> 
         </execution> 
       </executions> 

  </plugin>
web-applicationssecuritypasswords
3
dwjohnston

サンプルページに明確な警告がない場合、これはですひどい考えです。これは、開発者が開発者のマシンの構成ファイルに秘密を置くことを奨励します。これらのファイルはバージョン管理になってしまいますが、これは非常に間違っています。

構成ファイルにシークレットがある可能性がある唯一の場所（シークレットの意味については以下を参照）は、信頼できるシステム管理者のみがアクセスできる厳密に制御された運用サーバー上にあります。開発者のマシンでは、同じファイルがテンプレートとして提示される場合があります。

<configuration> 
    <adminurl>{{ADMIN_URL}}</adminurl>
    <user>{{ADMIN_USER}}</user> 
    <password>{{ADMIN_PASSWORD}}</password> 
    <upload>true</upload> 
    <action>deploy</action>
    ...
</configuration>

プレースホルダーは、展開中に実際の値に置き換えられます（ローカルデバッグ中に別の値に置き換えることができます）。

シークレット自体が保存される場合があります。

  • 別のバージョン管理では、
  • 暗号化されている
  • これには、新しいリビジョンを本番環境にプッシュするプロセスと、サーバーに完全にアクセスできる同じシステム管理者だけがアクセスできます。

リビジョンを本番環境にデプロイする場合、テンプレートを使用するよりも優れたオプションは、完全に別のファイルにシークレットを置くです。このファイルは暗号化されている場合があります（アプリを実行しているプロセスのみで解読できます）。つまり、開発者は実際の構成にアクセスできます（実際のadminurlとuserの値を確認できます）要素）デバッグ目的で、シークレット自体にアクセスすることはできません。

シークレットはデータベースに保存することもできます。単純なファイルと比較した場合の利点は次のとおりです。

  • 監査機能は、誰がいつどのシークレットにアクセスしたかを追跡する機能です。
  • すべてのシークレットが同じ中央の場所に保存されているため、セキュリティの管理、アクセス許可の取り消し、セキュリティが侵害されたシークレットのリセットなどが簡単になります。

欠点は次のとおりです。

  • 追加の複雑さ。これは、小さなアプリケーションにとっては圧倒的すぎる可能性があります（データベース用に個別の仮想マシンをデプロイする必要がある場合、それが保護されていることを確認し、このマシンからのログと監査が、次のように保護されている中央ログサーバーに送信されるようにします。まあ、など）
  • すべての秘密が同じ中央の場所に格納されているという事実は、攻撃者（不満を持つ従業員を含む）にとって完璧な標的になります。

ご了承ください：

  • シークレットとは、APIのシークレットキーなどを指します。 実際のユーザーのパスワードは絶対に保存しないでください：保存できるのはソルトハッシュのみで、プレーンなパスワード自体（暗号化されたバージョン）は決して保存できません。この例で使用されている「パスワード」という用語は、非常に誤解を招くものです。

  • weblogicはひどいユーザー名です。 Jeff Brownはユーザーです。 Cindy Colemanはユーザーです。 adminまたはwebまたはaccountingは、1人に対応していないため、ユーザーではありません。そのような名前は、複数の人の間で資格情報を共有することを奨励します（フリーランスやインターンを含むすべての開発者にrootパスワードを与えるか、解雇される人を含む会社の5人の会計士にaccountingパスワードを与えます来週）、それはひどい考えです。

  • パスワードweblogic123ユーザーweblogicは最悪です。例としてでも。パスワード {b>\27P1.TrFM2WU@I5dc|はもっと良い例です。

Windows Windowsでは、これはファイルの暗号化プロパティを指定することで可能です。復号化はアプリケーションに対して透過的に行われるため、アプリは暗号化キー（および暗号化キーのストレージ）を処理する必要がありません。他のオペレーティングシステムでも同じことが可能です。

4
Arseni Mourzenko