참고: 이 내용은 2022. 3. 9에 게시된 컨텐츠(Introducing SansShell: A Non-Interactive Local Host Agent)에서 번역되었습니다.
Snowflake에서 비대화형 로컬 호스트 관리 에이전트인 SansShell의 오픈 소스 릴리즈를 발표하게 되어 기쁩니다. 모든 유형의 서버 관리에 대한 강력한 인증, 권한 부여 및 감사를 가능하게 하는 것이 목적입니다. 소스 코드는 GitHub에서 확인할 수 있습니다.
기본적으로 SansShell은 코드에서 복잡한 서버 관리 작업을 정의하고 이러한 작업을 원격 클라이언트에 선택적으로 노출하는 방법을 제공하도록 설계되었습니다. 각 작업에는 호출자, 작업 유형 및 요청 내용을 기반으로 액세스를 제한할 수 있는 권한 부여 정책이 적용됩니다. 새로운 작업 유형을 쉽게 정의하고 불필요한 작업을 제거하거나 인증 및 정책 엔진을 교체할 수 있는 기능을 통해 모듈형 및 확장 가능형으로 구축되었습니다.
이는 일반적인 관리 작업(파일 읽기/수정, 명령 실행, 패키지 설치 등)의 참조 구현, 인증을 위한 mTLS 지원 및 Rego로 작성된 권한 부여 정책을 통해 경량 gRPC 서버로 구현됩니다.
SansShell의 비대화하여 특성을 통해 유지 관리 작업을 ‘안전한’ 것으로 미리 평가하고, 코드 검토하고, 정책에서 직접 인코딩할 수 있습니다. 또한 정확한 세부 작업을 감사할 수 있다는 매우 강력한 보증을 사용하여 ‘덜 안전한’ 작업을 허용할 수 있습니다. 또한 설계를 통해 이러한 작업에 대한 로컬 및 다자간 승인을 미리 요구할 수 있습니다(곧 제공될 기능). 이는 종속성이 매우 낮은 비상 액세스에 적합하며, 그와 동시에 필요한 조치에 대한 감사 로그를 훌륭하게 유지할 수 있습니다.
The SansShell 프록시
SansShell은 한 환경의 여러 컴퓨터, 혹은 모든 컴퓨터에 널리 배포할 수 있습니다. 인증 및 권한 부여 정책을 변경할 때는 예상치 않은 조정으로 인한 중단의 위험을 방지할 수 있도록 서두르지 않고 주의를 기울여야 합니다. 이 변경으로 인해 적극적인 문제 해결 또는 사고 대응과 같이 SanShell의 로컬 정책을 빠르게 발전시키는 것은 본질적으로 위험합니다. 또한 일부 작업(특정 파일의 체크섬 계산)은 많은 컴퓨터에서 수행되는 경구가 많으며 사용자의 워크스테이션에서 연속적으로 수행하려면 시간이 많이 소요되고 오류가 발생하기 쉽습니다.
SansShell에는 이 두 가지 문제를 모두 해결할 수 있도록 SansShell을 실행하는 사용자와 컴퓨터 간에 배포할 수 있는 스마트 프록시 서버가 포함되어 있습니다. 이 프록시는 세분화된 정책 적용 및 요청 로깅을 위한 단일 관리 지점을 제공하는 동시에 SansShell 서버에 단일 요청을 병렬로 ‘팬아웃’하는 기능을 제공합니다. 또한 사용자는 네트워크에 직접 액세스할 필요 없이 Sanshell 서버에 승인된 요청을 할 수 있으므로 각 엔드포인트의 네트워크 정책을 보다 제한적으로 설정할 수 있습니다. 프록시 계층의 정책 업데이트는 SansShell 서버를 실행하는 모든 엔드포인트를 변경할 위험 없이 더 빠르게 수렴될 수 있습니다.
SansShell을 구축하는 이유는 무엇일까요?
Snowflake는 고객 데이터를 가장 강력하게 보호하기 위해 노력하고 있습니다. 클라우드 VM을 관리하는 기존 방법에서는 추가 액세스 제한 및 감사를 위한 추가 계층이 있는 OpenSSH에 기반한 업계 모범 사례 도구를 활용합니다. 대부분의 인프라는 변경할 수 없거나 자동화에 의해 제자리에 업데이트되지만, 자동화가 처리할 수 없는 예상치 못한 상황에 신속하게 대응하거나 변경할 수 없는 모든 인프라를 재활용할 수 있는 것보다 더 빠른 속도로 비상 ‘임시 승인(Break glass)’ 액세스를 유지해야 합니다. 이와 같은 드문 경우라도 대화형 세션에서 비대화형 작업으로 마이그레이션하면 감사를 통해 공격 클래스 전체를 제거하여 상상할 수 있는 가장 정교한 위협도 안정적으로 감지할 수 있다는 확신을 얻을 수 있으며 자동화가 준비되지 않은 시나리오에 신속하게 대응할 수 있습니다.
VM 유지 보수 작업에서 이러한 문제를 해결하기 위해서는 프로덕션 호스트를 수정하기 위해 비대화형 API로 전환해야 할 필요가 있다는 생각이 들었습니다. 이는 변경 불가능한 인프라 모델에 아직 통합되지 않은 정기 유지 보수와 적극적인 사고 대응 시 불가피한 긴급 유지 보수 모두에 해당됩니다. 우리는 몇 가지 방안을 고려해보았지만 우리의 요구를 충족하는 솔루션을 찾지 못했습니다.
오픈 소스 SansShell을 사용해야 하는 이유는 무엇일까요?
현명한 오픈 소스 선택의 기본 원칙을 고려했을 때 이를 통해 업계를 최고 수준의 보안으로 이끌고 향후 Snowflake가 익숙하게 사용할 수 있는 호스트 관리에 대한 새로운 표준을 설정함으로써 이점을 누릴 수 있다는 것이 분명했습니다. 그리고 오픈 소스 모델이 제공할 수 있는 강화된 보안 조사의 이점을 누릴 수도 있을 것입니다. 우리는 FoundationDB와 마찬가지로 이렇게 ‘오픈 소스를 선택’하는 것이 업계와 당사에 이득이 될 것이라고 믿습니다.
Snowflake는 SansShell이 어떻게 인프라 관리를 개선할지 기대함과 동시에 단순한 고객 API에 계속 집중할 것입니다. 당사는 SansShell 및 FoundationDB와 같은 인프라 계층이 Snowflake의 내부 구현 세부 정보로 유지되는 것이 중요하다고 생각합니다. 그렇게 되면 시간이 지남에 따라 사용자에 대한 데이터 보안 및 거버넌스 스토리를 투명하게 개선할 수 있습니다. 당사가 단순하고, 성능이 우수하며, 안정적인 공개 API를 유지하기 위해 노력함으로써 고객은 인프라를 관리하는 대신 데이터에서 가치를 추출하는 데 집중할 수 있습니다.