web-dev-qa-db-ja.com

NATホストは要塞ホストから分離する必要があります

SSHアクセスを必要とするサーバーを備えたプライベートネットワークを用意します。インスタンスはプライベートサブネット内にあるため、SSH経由で直接アクセスすることはできず、アクセスするにはパブリック要塞ホストが必要です。

Workstation -> via SSH -> Bastion -> via SSH Forwarding -> private subnet instnce

NATホストをプライベートネットワークへのパブリックゲートウェイとして使用します。

User -> via HTTP -> NAT -> via private networking -> private subnet instance

Bastion＆NATホストを分離しておくことの利点は何ですか？それらを組み合わせる利点は何ですか？

securitynatnetworkingbastion
1
csi

技術的な観点からは、NATを要塞ホストとして使用できますが、アーキテクチャの観点からは絶対に使用しないでください。理由は次のとおりです。

要塞ホストは内部インフラストラクチャへのエントリポイントであり、NATは通常、データベースなどの重要なサービスをインターネットに接続します。したがって、両方を可能な限り保護する必要があります。

要塞ホストとNATには反対の役割があります：

  • 要塞ホストは、（限られたIP範囲からの）インターネットからの接続の開始を許可し、インターネットへのすべての開始トラフィックを拒否する必要があります
  • NATは、インターネットからのすべての開始トラフィックを拒否し、内部ネットからインターネットへの開始トラフィックを許可する必要があります

また、要塞ホストは単なる管理サーバーであるため、通常は安価なインスタンスで十分ですが、NATは、大量のトラフィックをルーティングできる可能性があります。

セキュリティを気にしないことを除いて、要塞ホストとしてNAT）を使用する必要がある合理的な理由はありません;-)

1
zebra

あなたが説明した要塞ホストは、一言で言えばジャンプホストであり、「ネットワーキング」から始まり、それ以上のOSIレベルでアクセスを集中制御できます。そのような単一のホストへのアクセスを、そこでのユーザー名とキーによって制限することができ、それで十分です。そこにあらゆる種類の監査/コマンドロギングをデプロイすることもできます。

NATはネットワークレベルを意味しますのみ —プロトコル、送信元および宛先IP（およびポート）を制御できますが、ほとんどはそれだけです。

それらを組み合わせることについて話すとき、唯一の可能な影響は、それら2つの間の望ましくない干渉による可能性があります。最悪のシナリオ：

  • NATの誤用により、SSHが要塞ホスト自体にログインできるようになります（ほとんど不可能、ほぼ不可能）
  • ジャンプホストへのログインを許可されたユーザーは、NATルールを台無しにします（理論的には可能ですが、制限するのは比較的簡単です。SSHユーザーは定義上信頼できるユーザーであることに注意してください。つまり、マイナーな異議です）
  • トレースが混在しています。強制的に分離しない限り、BastionのホストローカルユーザーのトラフィックとNATを区別することはできません。正当なロギングがあれば問題ありません。 NATおよびSSH環境に専用IPを使用すると、これも解決されます。BastionのSSHローカルユーザーが発信接続の確立も許可されていない場合は問題ありません。
0
poige