Architecture-center: 점프 박스를 더 이상 사용하지 않을 수 있습니까?

신고해 주셔서 감사합니다. 이 문제는 검토 중입니다. 이것은 Microsoft 내부 DevOps 버그 ID AB#210868입니다.

@bagira-kr 감사합니다. 일반적으로 말해서 더 이상 아키텍처의 일부로 리터럴 점프 상자를 사용하여 새 콘텐츠를 만들지 않고 대신 가능한 경우 Azure Bastion을 사용하는 것을 선호합니다. 기존 아키텍처 페이지를 다시 방문할 때 점프 상자를 Azure Bastion으로 대체하는 것이 고려 대상 범위에 있습니다. 그 변화를 반영하기 위해 특정 기사가 언제 업데이트될 것인지 타임라인이 없습니다.

@ckittel 설명을 제공

@bagira-kr 당분간은 이 글을 닫도록 하겠습니다. 관련하여 더 궁금한 사항이 있으시면 댓글로 저를 태그해 주시기 바랍니다. 우리는 기꺼이 토론을 계속하고 문제를 다시 열 것입니다.

이해가 안 돼요. 문제가 해결되지 않은 경우 문제를 종료하는 이유는 무엇입니까?

@bagira-kr 차드가 이미 해명했습니다. 더 찾고 있는 것이 있습니까?

@DixitArora-MSFT 예 이 문제는 아키텍처 문서에서 jumpbox의 사용 중단을 위한 것입니까? 전반적인 계획이 있다고 언급했지만 문제는 여전히 미해결 상태입니다.

향후 개정판에서 배스천으로 점프박스를 대체하는 것과 관련하여 이것은 규모에 따라 확립되거나 입증된 패턴이 아니며 원격 액세스를 위한 배스천과 동일한 문제가 존재하므로 보다 유연한 것이 모범 사례로 제공되거나 시장에서 확립된 선례로 제공되어야 합니다. 사용자가 셸 또는 RDP 액세스를 위해 웹 브라우저를 사용하도록 강제하는 것은 허용되는 솔루션이 아닙니다.

가상 네트워크 피어링 또는 이와 유사한 VPN 액세스는 중대형 환경에 대해 확립된 패턴입니다. 인증된 양말 프록시조차도 단일 공급업체에서만 제공하는 이 새로운 서비스보다 환경 진입에 더 많이 사용됩니다(권장하지 않음). 이는 일반적인 클라우드 아키텍처 문제 영역에 속하더라도 MSFT Azure의 컨텍스트입니다. 시스템 인터페이스가 있는 일부 사용 사례는 고려되지 않고 있다고 생각합니다.

MSFT Azure 복합 서비스 제품을 사용하려는 욕구를 확실히 이해할 수 있지만 모범 사례로 사용할 수 있는 보다 일반적인 접근 방식이 있습니다. 아키텍처 문서를 작성할 때 해당 문서의 소비자에게 안전하게 가정된 영향으로 인해 "일반적인 우선" 접근 방식을 탐색할 수 있습니까?

(반복 편집 죄송합니다 -- 오늘은 영어가 어렵습니다)

bagira-kr에 100% 동의합니다. 저는 이것을 처음 보는 보안 담당자입니다. 우리가 새로운 사용자에게 1990년대에 속한 일을 하는 방법을 가르치고 있다는 사실에 깊이 우려하고 있습니다. 이것은 MSFT와 Azure가 본질적으로 안전하지 않거나 보안에 관심이 없다는 아이디어를 공표합니다.

필요한 변경 없이 문제를 닫는 것은 여기서 매우 실제적인 문제를 해결하는 데 아무런 도움이 되지 않습니다. 보안 팀에서 리소스를 가져와 그에 따라 문서를 업데이트할 것을 제안합니다.