Ansibleセキュリティのベストプラクティス

データセンターにAnsibleを導入し、制御マシンの場所とSSHキーの管理方法に関するセキュリティのベストプラクティスを探しています。

質問1：制御マシン

もちろん、制御機が必要です。制御マシンには、公開SSHキーが保存されています。攻撃者がコントロールマシンにアクセスできる場合、潜在的にデータセンター全体（またはAnsibleが管理するサーバー）にアクセスできます。それでは、データセンターに専用の制御マシンまたはリモート制御マシン（データセンターにリモート接続されたラップトップなど）を使用する方が良いでしょうか？

ベストプラクティスがラップトップを使用することである場合（もちろん盗まれる可能性がありますが、公開キーをクラウドで安全に保存するか、暗号化されたポータブルデバイスでオフラインで保存できます）、Webインターフェイスを使用する必要がある場合Ansible、Ansible Tower、Semaphore、Rundeck、またはForemanのように、中央マシンからデータセンターにインストールする必要がありますか？「単一の攻撃ポイント」になるためにそれを保護し、回避する方法は？

質問2：SSHキー

ルートで実行する必要のあるタスク（ソフトウェアパッケージのインストールなど）を作成するために、Ansibleを使用する必要があるとします。ベストプラクティスは、制御されたサーバーでrootユーザーを使用するのではなく、sudo権限を持つAnsibleの通常ユーザーを追加することだと思います。しかし、Ansibleがほぼすべてのタスクを実行する必要がある場合、sudoを介してすべてのコマンドにアクセスする必要があります。だから、最良の選択は何ですか：

• Ansibleにrootユーザーを使用させます（公開キーは ~/.ssh/authorized_keys
• sudoアクセスでAnsible専用の非特権ユーザーを作成します
• Ansibleユーザーがパスワードを指定してsudoを介してすべてのコマンドを実行できるようにする
• Ansibleユーザーがパスワードを指定せずにsudoを介してすべてのコマンドを実行できるようにする
• 他のヒントはありますか？

要塞ホスト（ansible Control Center）は、別のサブネットに属します。外部から直接アクセスできないようにし、管理対象サーバーから直接アクセスできないようにします。

あなたのラップトップは、最も安全性の低いデバイスです。1つの愚かなメール、1つの愚かなフラッシュの脆弱性、1つの愚かなゲストWifi、そしてそれはpwnedされます。

サーバーの場合、sshを介したルートアクセスを許可しないでください。多くの監査はこれをsc笑します。

ansibleでは、すべての管理者が各ターゲットサーバーで独自の個人アカウントを使用し、パスワードを使用してsudoを許可します。この方法では、2人の間でパスワードは共有されません。各サーバーで誰が何をしたかを確認できます。個人アカウントでパスワードによるログイン、sshキーのみ、またはその両方が必要な場合は、あなた次第です。

ansibleを明確にするために、単一のターゲットログイン名を使用する必要はありません。各管理者は、個人のターゲットログイン名を持つことができます。

補足事項：パスワードがある場合は、何らかの単語（「ansible」、「admin」、「cluster」、「management」、または「operator」など）と呼ばれるアカウントを作成しないでください。パスワードを持つアカウントの唯一の適切な名前は、「jkowalski」のような人間の名前です。アカウントを介して行われたアクションに対して責任を負うことができるのは人間だけであり、パスワードを不適切に保護する責任があります。

>質問1：制御マシン

Userify（完全開示：sshキーを管理するソフトウェアを実際に提供しています）では、最大のSSHキーウェアハウスも運営しているため、常にこれに対処しています。一般的に、クラウドを使用するよりもローカルにインストールすることをお勧めします。制御を強化し、表面積を減らすため、既知の信頼できるネットワークにのみロックダウンできるためです。

覚えておくべき重要なことは、このように適切に構築されたシステムでは、攻撃者に漏えいする可能性のある重要な秘密は実際にはないはずだということです。誰かがあなたのデータセンターにフォークリフトを運転し、あなたのサーバーを持ち去ったら、彼らはいくつかの重くハッシュされたパスワード、おそらくいくつかの重く暗号化されたファイル、および対応する秘密鍵のないいくつかの公開鍵を除いて多くを得ることはありません。言い換えれば、それほどではありません。

あなたが指摘するように、ここでの実際の脅威ベクトルは、攻撃者がそのマシンを制御し、それを使用して自分のユーザーアカウントと（公開）キーを展開した場合に発生するものです。これは、事実上すべてのクラウドプラットフォーム（例：Linode）のリスクです。コントロールプレーンへのアクセスの防止に最も強く集中する必要があります。これは、攻撃対象領域を最小限に抑え（少数のポートのみを公開し、それらのポートを可能な限りロックダウンする）、できれば特権エスカレーションおよびさまざまな攻撃に対して強化されたソフトウェアを使用することを意味します（ SQLインジェクション、XSS、CSRFなど）コントロールプレーンへの2FA / MFAアクセスを有効にし、可能な限りそのコントロールプレーンのロックダウンに焦点を当てます。

それでは、データセンターに専用の制御マシンまたはリモート制御マシン（データセンターにリモート接続されたラップトップなど）を使用する方が良いでしょうか？

それはだ間違いなく良いあなたはそれを隔離し、盗難や不正アクセスのリスクを最小化/防止することをロックダウンすることができますので、安全なデータセンターに専用の制御マシンを持っています。

ベストプラクティスは、（もちろん、盗まれる可能性がありますが、私は自分の公開鍵を安全にポータブル暗号化されたデバイス上のクラウドまたはオフラインでオンライン保存されている可能性がある）私のラップトップを使用する場合、私はいくつかのWebインタフェースを使用する必要がある場合はどのようにAnsible、Ansible Tower、Semaphore、Rundeck、またはForemanのように、中央マシンからデータセンターにインストールする必要がありますか？

多数のユーザーとサーバー間での異なるレベルの承認または追加の必要性が原因で管理の問題が発生し始めるまで、キー（Userifyを含む）を管理するためにWebインターフェイスまたはセカンダリコントロールプレーンを実行する必要はありません。キーを更新するためのAnsibleの知識やアクセス権を持っていない可能性のあるユーザーのための手持ち。最初はUserifyは多くのシェルスクリプトに過ぎず（おそらく今日はAnsibleになっているでしょう！）、追加の管理制御と人々が管理/回転するための簡単な方法が必要になるまで、まったく問題はありません。独自のキー。（もちろん、その点に到達したらUserifyを見てください！）

「単一の攻撃ポイント」になるためにそれを保護し、回避する方法は？

もちろん、ネットワーク上のすべてのリソースをチェックして、ロックダウンを行いますが、最も重要なことは、安全な基盤から始めることです。

1.最初からセキュリティを念頭に置いてソリューションを設計します。従来は問題が少なかったテクノロジー（データベース、言語など）を選択し、セキュリティを念頭に置いてコーディングします。信頼できるユーザーからでも、すべての受信データをサニタイズします。パラノイアは美徳です。

2.最終的に、すべてが壊れます。発生した場合の被害を最小限に抑えます。すでに指摘したように、秘密資料の取り扱いを最小限に抑えてください。

3.シンプルにします。最新のエキゾチックなことは、セキュリティを測定可能かつ証明可能に向上させることが確実でない限り実行しないでください。たとえば、暗号化レイヤーにAESよりもX25519 / NaCl（libsodium）を選択しました（安静時および移動中のすべてを暗号化します）。これはもともと信頼できる人（DJBなど）によって設計および作成され、世界でレビューされたためです-シュナイアーやGoogleのセキュリティチームなどの有名な研究者。単純なために深いバグを隠すのが難しくなるため、単純なものほど新しいものを使用してください。

4.セキュリティ標準を満たします。PCIやHIPAAセキュリティルールのようなセキュリティ体制に陥っていない場合でも、それらの標準を読み、それらを満たす方法、または少なくとも非常に強力な代替コントロールを見つけてください。これにより、「ベストプラクティス」を確実に満たすことができます。

5.外部/独立侵入テストを実施し、バグ報奨金を実行して、継続的にこれらのベストプラクティスに従っていることを確認します。賢くてやる気のある人がそれを叩くまでは、すべてが素晴らしく見えます...それが終わったら、ソリューションに大きな自信を持つことができます。

質問2：SSHキー最良の選択は何ですか：Ansibleにルートユーザーを使用させます（公開キーを保存~/.ssh/authorized_keys/ Ansibleユーザーにsudoを介してすべてのコマンドを実行させ、パスワードを指定します（すべてのsysadminに固有のニーズがあります） Ansibleを使用してそのサーバーを制御します）

sudoであっても、サーバーでパスワードを使用しないようにしてください。それは秘密を扱っており、最終的にあなたのセキュリティを損なうでしょう（あなたは本当にマシン間でそのsudoパスワードを非常に簡単に変えることはできません、あなたはそれをどこかに保存する必要があり、パスワードはあなたが本当にまた、SSHをデフォルトのままにしておくと、これらのパスワードがブルートフォースされる可能性があり、キーが無意味になります。また、任意の目的、特にリモートログインでrootユーザーを使用しないでください。

sudoアクセスでAnsible専用の非特権ユーザーを作成する/ Ansibleユーザーがパスワードを指定せずにsudoを介してすべてのコマンドを実行できるようにする

まさに。sudoロールを使用して、ansibleに戻って監査できる非特権ユーザー。理想的には、sudoアクセス（パスワードなし）を使用したサーバー間の通信に対応した標準ユーザーを作成します。

... NB、Userifyを使用している場合、ansibleのUserifyユーザーを作成することをお勧めします（複数のansible制御マシンがある場合は、プロジェクトまたはサーバーグループごとに分割することもできます）。制御サーバー上のSSHキー、およびそのUserifyプロファイルページで公開キーを提供します。（このテキストボックスは本質的にになります/home/ansible/.ssh/authorized_keys）。ansibleシステムアカウントは、リモートバックアップアカウント、シークレット管理など、他のサーバー間システムアカウントとは別にする必要があります。次に、人間を招待すると、独自のキーも作成および管理でき、すべてが分離されます。ただし、Ansibleコントロールサーバーをロックダウンするのと同じように、同じ方法でUserifyサーバー（または展開するソリューション）をロックダウンしてみてください。

他のヒントはありますか？

あなたは間違いなくこれについて正しい方法で正しい質問をしていると思います。この種のことについて議論したい場合は、私にメール（userifyでの最初のドットの姓）を送信してください。がんばろう！

回答1：制御マシン

両方とも、ラップトップを使用して要塞ホスト経由でサーバーに接続できます。何かのようなもの：

Host private1
  IdentityFile ~/.ssh/rsa_private_key
  ProxyCommand ssh user@bastion -W %h:%p

Host bastion
  IdentityFile ~/.ssh/bastion_rsa_key

要塞ホストの詳細

要塞サーバー用のキーと、その背後のホスト用の別のキーがある場所。（個人的にはgpg-agent / ssh-agentを使用します）

回答2：認証

「ansible」の特定のベストプラクティスが他のssh接続のベストプラクティスとどのように異なるかはわかりませんが、いや、サービスアカウントやルートアカウントではなく、自分自身としてansibleを実行する必要があります。

次の認証の組み合わせ：

• ユーザーごとのsshキー（中央に保存）
• Kerberos認証
• 多要素認証（Yubikeys、Duo、GoogleAuthなど）
• Fail2ban / account-lockout
• 集中ログとアラート
• 集中認証（FreeIPA、LDAP、IdM、MS AD）
• internal-caでsshキーに署名する

他の考え：

• 常に秘密/個人情報をansible-vaultに保存してください。
• Ansibleの実行にはSUDO / Rootは必要ありませんが、sudo / rootが必要な場合を除きます。
• Ansibleはさまざまな方法で権限を昇格できます

最後に、ウィンドウについては何も言及していませんでした。したがって、これを使用していないと推測できます。ただし、この場合、デリゲートオプションを使用して、ラップトップで要塞ホスト（delegate_to bastion.hostname.fqdn：）とkerberosチケットでkerberos / winrm httpsを使用します。

あなたがそれを逃した場合、コンピューティングのベストプラクティス、ルートとして何もしないで、常に名前付きアカウントを使用してください