Architecture-center: Können wir Sprungboxen verwerfen?

Vielen Dank für die Meldung. Dieses Problem wird derzeit überprüft. Dies ist eine Microsoft interne DevOps- Fehler- ID

Danke @bagira-kr - Generell erstellen wir keine neuen Inhalte mehr mit wörtlichen Jumpboxen als Teil der Architektur, sondern bevorzugen nach Möglichkeit die Verwendung von Azure Bastion. Wenn wir vorhandene Architekturseiten erneut aufrufen, kommt das Ersetzen von Jumpboxen durch Azure Bastion in Betracht. Wir haben keinen Zeitplan, wann ein bestimmter Artikel aktualisiert wird, um diese Verschiebung widerzuspiegeln.

@ckittel Danke für die Klarstellung.

@bagira-kr Vorerst werde ich mit dem Schließen fortfahren und wenn es weitere Fragen zu dieser Angelegenheit gibt, markieren Sie mich bitte in Ihrer Antwort. Wir werden die Diskussion gerne fortsetzen und das Thema erneut aufgreifen.

Ich verstehe nicht. Warum sollten wir ein Problem schließen, wenn es nicht behoben wird?

@bagira-kr Tschad hat die Klärung bereits vorgenommen. Gibt es noch etwas, wonach Sie suchen?

@ DixitArora-MSFT Ja, dieses Problem betraf die Einstellung von Jumpboxen aus der Architekturdokumentation? Es wurde erwähnt, dass es einen allgemeinen Plan gibt, aber das Problem ist noch offen.

Was das Ersetzen von Jumpboxen durch Bastion in zukünftigen Überarbeitungen betrifft, so ist dies kein etabliertes oder gar bewährtes Muster im Maßstab, und etwas flexibleres sollte als Best Practice oder sogar als etablierter Präzedenzfall auf dem Markt angeboten werden, da die gleichen Probleme mit Bastion für den Fernzugriff bestehen. Benutzer zu zwingen, einen Webbrowser für den Shell- oder RDP-Zugriff zu verwenden, ist keine akzeptable Lösung.

VPN-Zugriff mit virtuellem Netzwerk-Peering oder ähnlichem ist ein etabliertes Muster für mittlere und große Umgebungen. Sogar nur ein authentifizierter Socks-Proxy wird stärker für den Zugang zu einer Umgebung verwendet (obwohl ich ihn nicht empfehle) als dieses neue Serviceangebot, das nur von einem einzigen Anbieter bereitgestellt wird - dies ist eine generische Cloud-Architektur-Problemdomäne, selbst wenn sie in der Kontext von MSFT Azure. Ich denke, einige Anwendungsfälle mit Systemanbindung werden dort nicht berücksichtigt.

Ich kann zwar den Wunsch verstehen, ein MSFT Azure Composite Service-Angebot zu verwenden, es gibt jedoch allgemeinere Ansätze, die als Best Practices dienen können. Können wir beim Schreiben von Architekturdokumentationen aufgrund der sicher angenommenen Auswirkungen dieser Dokumentation auf die Verbraucher einen "generic first"-Ansatz untersuchen?

(Entschuldigung für die wiederholten Änderungen – Englisch ist heute schwer)

Stimme zu 100% mit bagira-kr. Ich bin ein Sicherheitsexperte, der sich das zum ersten Mal anschaut, und bin zutiefst besorgt darüber, dass wir neuen Benutzern eine Vorgehensweise beibringen, die in die 1990er Jahre gehört. Dies verbreitet die Idee, dass MSFT und Azure entweder von Natur aus unsicher sind oder sich nicht um die Sicherheit kümmern.

Das Schließen des Problems, ohne eine erforderliche Änderung vorzunehmen, hilft hier nicht, ein sehr reales Problem zu beheben. Schlagen Sie vor, dass Sie eine Ressource von einem Sicherheitsteam abrufen und Ihre Dokumentation entsprechend aktualisieren.