☰

自動展開中にパスワードをどう処理するか?

tag-icon • tag-icon linux security password credentials
自動展開中にパスワードをどう処理するか?

責任ある管理者として、私たちは次のようなよくある弱点を知っています。

しかし、実際にはこれにどう対処すればよいのでしょうか?

もちろん、SSH 経由のパスワードレス認証や sudo などのツールなどのテクノロジーを使用すると、重要な場所に保存されているログイン資格情報を削除することができ、これは Linux サーバーの自動展開時に非常に役立ちます。

しかし、オペレーティング システムを離れてアプリケーションをインストールするとすぐに、パスワードを安全に保管する場所という問題に直面する可能性が高くなります。

たとえば、データベース サーバーをインストールする場合、クリアテキスト パスワードを Web アプリケーションの構成ファイルに保存する必要がある可能性が高くなります。

次に、管理者だけが資格情報を表示できるように構成ファイルを保護し、セキュリティへの影響を最小限に抑えるためにデータベース ユーザーのアクセス権限を制限する必要があります。

しかし、例えばメインの管理データベースアカウントをどう扱うか？少なくともDBAはそれを知っているはず（そのため、どこかに平文が必要です）であり、OS管理者としてはない資格情報を知っている。あるいは、デプロイメントはDevOpsによって行われ、彼らは知らないはずである。どれでも運用サーバー上の資格情報の。

可能な解決策

これを長期間検討した結果、3 つの解決策が思い浮かびましたが、それぞれに弱点があります。

  1. 展開中にランダムな認証情報を生成し、それをデータベースに書き込み可能な形式で保存します。また、たとえば DBA には、データベース認証情報のみを読み取ることができる別のユーザーがいます。しかし、たとえば Web アプリケーションの構成ファイル内のクリアテキスト パスワードをどのように処理すればよいでしょうか。ルート ユーザーはそれらを読み取ることができます。また、パスワード データベースのルート ユーザーは、それを読み取る可能性があります。全てパスワード資格情報。

  2. 展開中にクリアテキストのパスワードとデフォルトの資格情報を受け入れ、変更するポストスクリプトを追加します。すべてパスワード。スクリプトの実行中に権限のある人が資格情報を入力する必要がある対話型の場合もあります。

  3. 信頼できる第三者の鍵を使ってパスワードを非対称的に暗号化します。パスワードが要求されると、でなければなりませんその後変更されました。

どう思いますか? ここにベストプラクティスはありますか?

答え1

  1. すべての資格情報を安全に暗号化したデータベースに保存する必要があります
  2. 展開中はファイアウォールによってサーバーは外部から完全にアクセスできないようにする必要があります。
  3. スクリプトでランダムパスを生成し、それをメールで送信するのは問題ありません。
  4. サーバーがプロビジョニングされた後、一般のユーザーにアクセスを許可する前にパスワードを変更しても問題ありません。
  5. パスワードを自分自身にメールで送信することは、社内メール サーバーを使用し、SMTP 経由でパブリックにルーティングされない限り、問題ありません (SMTPS は別の話です)

電子メールは、ほぼすべてのプロトコルに置き換えることができます。パスワードをどこかに sftp で送信したり、onetimesecret API を使用して 1 回限りのメッセージを作成したり、https を使用してプライベート gist にアップロードしたり、その他考えられるあらゆる方法で行うことができます。

大体これで全部だと思います。

関連情報