SaaS 기능으로 보안을 구축하는 방법: 가이드

이 게시물에서는 SaaS 플랫폼과 더욱 세밀하고 안전한 연결을 제공하는 방법을 보여 드리겠습니다. 최종 결과는 SaaS 플랫폼의 자연스러운 확장처럼 보이고 느껴지며 기업 중심 계획의 기능으로 제공되거나 모든 고객에게 경쟁 차별화 요소로 제공되는 전체적인 솔루션입니다. 데모를 실행하는 데 필요한 총 시간은 단 몇 분입니다. 또한 마법이 어떻게 작동하는지 설명하기 위해 뒤에서 무슨 일이 일어나고 있는지 깊이 파헤쳐 보겠습니다.

먼저, 이러한 특정 요구가 발생하는 이유에 대한 배경 지식을 제공하고 기존 구현의 단점을 강조하겠습니다. 왜냐하면 그러한 오래된 접근 방식은 더 이상 작동하지 않기 때문입니다.

보안을 하나의 기능으로 생각해야 합니다. 엔지니어링 부사장이라면 제품 관리자, 제품 소유자라면 보안에 시간을 투자하고 개발자가 더 좋고 안전한 인프라를 만들 수 있도록 하세요.

— Joel Spolsky , Stack Overflow 창립자

향후 10년 동안 가장 성공적인 제품은 현상 유지 접근 방식으로는 더 이상 충분하지 않다는 것을 깨닫는 제품이 될 것입니다. 이에 대해 조엘의 말을 받아들일 필요도 없습니다. Apple이 최근 발표한 프라이빗 클라우드 컴퓨팅 에 대한 세부 정보를 읽어보세요. 지난 20년 동안 가장 성공적인 기업 중 하나는 보안, 개인 정보 보호 및 신뢰가 핵심 차별화 요소가 될 것이라는 점을 분명히 밝힌 것입니다.

그들은 심지어 TLS와 같은 현재의 프로토콜 사용이 어떻게 고객이 기대해야 하는 엔드투엔드 보안 및 개인 정보 보호 보장을 제공할 수 없는지에 대해서도 논의합니다.

나는 수년 전에 시스템을 서로 연결하는 작업을 했는데, 이는 내 경력의 초기 단계에 노동 집약적인 작업이었습니다. 우리 회사는 성장하고 있었고 현재 건물의 서버실을 새 건물에 방금 설치한 시스템으로 패치했습니다. 새 사무실은 길에서 몇 블록 떨어진 곳에 있었고 우리는 지역 통신사와 협력하여 전용선을 설치하고 있었습니다.

당시에는 두 개의 별도 네트워크를 연결하는 것이 명백하고 물리적으로 확실한 현실이었습니다.

우리 모두는 그 시절부터 계속 나아갔습니다. 이제 현대 기술 스택은 더욱 복잡해졌습니다. '최고의' 제품 회사가 클라우드에서 실행하며 전 세계에 퍼져 있는 일련의 상호 연결된 앱입니다. 수십 년에 걸쳐 우리는 진화했습니다. 오늘날 서로 다른 두 회사가 실제로 전체 네트워크를 서로 연결하려는 경우는 거의 없습니다. 통신해야 하는 것은 각 네트워크 내의 특정 앱과 워크로드이기 때문입니다.

그러나 우리는 시스템을 "안전하게" 연결하는 방법으로 기존 접근 방식을 계속 사용해 왔습니다.

실제 케이블 연결은 추상화되었지만 사실상 동일한 작업을 수행하고 있습니다. 이러한 오래된 접근 방식은 셀 수 없이 많은 네트워크에 일시적으로 노출되며, 이는 악용할 수 있는 엄청난 공격 표면입니다.

개인 시스템에 연결해야 할 필요성

사람들이 "클라우드" 또는 "온프레미스"라고 말할 때 의미가 지난 수십 년 동안 모호해졌습니다. 혼란을 피하기 위해 다음과 같은 가상 시나리오를 만들어 보겠습니다.

• Initech 플랫폼: 귀하가 운영하는 SaaS 플랫폼입니다. 탄력적이고 확장 가능하며 주요 클라우드 제공업체 중 하나에서 호스팅됩니다. 고객은 여러 가지 유용한 지표에 대한 가시성을 제공하고 개발 워크플로에 직접 유용한 피드백을 제공하므로 DevOps 프로세스를 개선하기 위해 플랫폼을 구입합니다.

• ACME Corp: 귀하가 지원하고 싶은 Initech의 대규모 고객입니다. 그들은 다양한 위치에서 많은 인프라를 운영합니다. 자체 데이터 센터 내부에 있다는 고전적인 의미에서 "온프레미스"입니까? 주요 클라우드 제공업체 중 하나의 자체 VPC 내에 있습니까? 그것은 중요하지 않습니다! 고객 시스템은 Initech가 제어하지 않고, 당사가 액세스할 수 없고, 공용 인터넷에서 직접 액세스할 수 없는 하나 이상의 네트워크에서 실행되고 있습니다.

개발자 워크플로에 적극적으로 참여

Initech 플랫폼의 초기 버전을 구축할 때 제품 시장 적합성을 입증하기 위해 협력할 잠재 고객이 많이 있습니다. 주요 버전 제어 시스템 제공업체(예: GitHub, GitLab, Bitbucket 등)의 공개 API와 통합되고 커밋/웹후크를 사용하여 이벤트에 반응하고 결과를 워크플로에 푸시하며 모든 것이 예상대로 작동합니다.

제품이 수동적이고 ACME Corp의 누군가가 시작한 이벤트에 단순히 반응하는 동안 이는 훌륭합니다. 많은 서비스는 세계의 외부 변화를 평가하고 고객을 위한 개선을 주도하는 데 적극적으로 참여함으로써 가치를 제공하기를 원합니다.

많은 종속성 또는 보안 검색 서비스를 생각해 보십시오. 새로운 취약성이 공개되면 영향을 받는 모든 저장소에 대해 가능한 한 빨리 풀/병합 요청을 생성하려고 합니다. 공개 API를 갖춘 완전 관리형 VCS 서비스는 이를 활성화하는 방법을 제공하지만, 이러한 제품의 자체 호스팅 버전에는 공개적으로 액세스 가능한 API가 없습니다.

이러한 시스템을 자체 호스팅하기로 선택한 고객은 일반적으로 대기업에 치우쳐 있으므로 이제 우리는 몇 가지 어려운 결정에 직면하게 되었습니다. Initech는 이러한 고가치 고객에게 제품을 판매할 수 없습니까? 고객은 가장 중요한 기능 중 하나가 누락된 제품의 축소 버전을 구입해야 합니까? 아니면 Initech에 액세스 권한을 부여하기 위해 보안 및 네트워킹 상태의 일부 측면을 재평가하도록 요청합니까?

개인 데이터에 대한 접근

Initech는 사용자 정의 보고 솔루션을 표시하기 위해 데이터베이스를 쿼리해야 합니다. 거의 모든 CDP(고객 데이터 플랫폼) 또는 시각화 도구에 동일한 문제가 있기 때문에 이는 Initech만의 문제가 아닙니다. 고객은 공용 인터넷에서 자신의 개인 데이터에 액세스하는 것을 원하지 않으므로 일반적으로 이러한 데이터는 프라이빗 서브넷의 데이터베이스.

현재 접근 방식의 문제점

앞서 말했듯이 최신 기술 스택은 일련의 상호 연결된 앱으로 발전했습니다. 그러나 이러한 앱을 연결하는 방식은 수십 년 전에 네트워크를 연결한 방식과 약간만 변경되었습니다. 이러한 접근 방식은 편리하고 익숙하지만 오늘날의 사용 사례에 맞게 설계되지 않았습니다.

대신 그들은 오늘날 우리가 필요로 하는 방식에 가까워지기 위해 예전에 작동했던 방식을 가능한 한 최소한으로 조정하려고 시도하고 있습니다.

공용 인터넷에 시스템 배치

대부분의 개인 시스템에 대한 기본 배포 옵션은 공용 IP 주소 없이 개인 서브넷이 있는 개인 네트워크에 시스템을 배치하는 것입니다. 여기에는 아주 좋은 이유가 있습니다! Initech가 이 개인 시스템에 연결하는 가장 쉬운 방법은 ACME Corp에 인터넷에서 액세스할 수 있는 공용 IP 주소나 호스트 이름을 제공하도록 요청하는 것입니다.

이것은 나쁘다.

처음에 시스템을 세상과 단절된 개인 네트워크에 배치하는 모든 좋은 이유는 즉시 사라집니다. 이제 이 시스템은 전체 공용 인터넷에서 접속할 수 있으므로 수천 명의 해커가 시스템에 무차별 공격을 가하거나 단순히 DoS를 시도할 수 있습니다. 단일 유출된 자격 증명, CVE 또는 기타 문제로 인해 소유권을 얻을 수 없습니다.

역방향 프록시

또 다른 접근 방식은 시스템 앞에 역방향 프록시를 배치하는 것입니다. 나는 nginx나 HA Proxy 같은 것에 대해서만 이야기하는 것이 아닙니다. 이 설명에 맞는 호스팅 또는 관리 서비스의 전체 범주도 있습니다.

이는 ACME Corp이 더 이상 개인 시스템을 공용 인터넷에 직접 배치하지 않는다는 장점이 있습니다. 역방향 프록시는 또한 잠재적인 DoS 공격을 완화하기 위해 속도를 제한하거나 액세스 제한을 미세 조정하는 기능을 추가합니다. 이는 심층적인 방어 개선이지만 ACME Corp에서는 여전히 전체 공용 인터넷이 프록시에 접근하여 공격을 시도하도록 허용하고 있습니다.

손상된 경우 프록시가 수행하는 작업을 수행합니다. 즉, 트래픽이 의도한 대상으로 전달되도록 합니다.

IP 허용 목록

점진적인 개선 사항은 Initech가 요청을 보낼 IP 목록을 제공하고 ACME Corp가 방화벽과 라우팅 규칙을 관리하여 해당 IP 주소에서만 요청을 허용하도록 하는 것입니다. 하지만 이는 그다지 개선되지 않았습니다.

Initech에서는 현재 앱 인스턴스와 IP 주소가 긴밀하게 결합되는 것을 원하지 않을 것입니다. 고객에게 새로운 IP 주소를 지속적으로 알릴 필요 없이 필요에 따라 인프라를 확장할 수 있는 유연성이 필요합니다.

따라서 IP 주소는 NAT 게이트웨이 또는 프록시 서버에 속할 가능성이 높습니다. ACME Corp은 하나 또는 두 개의 소스 IP 주소에만 액세스를 잠그는 것은 하나 또는 두 개의 원격 시스템만 네트워크에 액세스할 수 있음을 의미한다고 가정할 수 있습니다.

현실은 NAT 게이트웨이나 프록시를 통해 요청을 보낼 수 있는 원격 네트워크의 모든 항목에 이제 ACME Corp 네트워크에 대한 액세스 권한이 부여된다는 것입니다. 이는 단일 앱이나 컴퓨터를 허용하지 않습니다. 전체 원격 네트워크를 허용했습니다.

하지만 더욱 우려되는 점은 IP 소스 주소가 사소하게 스푸핑 된다는 것입니다. 잠재적인 공격자는 올바른 형식의 요청을 생성하고, 소스 주소를 스푸핑하고, ACME Corp 네트워크에 데이터나 지침을 보낼 수 있습니다. Initech를 포함한 SaaS 공급업체는 필연적으로 현재 IP 주소 목록을 문서화하여 가장하려는 IP 목록이 미리 만들어지도록 해야 합니다.

IP 필터링에 대한 접근 방식이 정교할수록 공격자가 IP를 손상시키려면 더욱 정교해야 하지만 어느 것도 완벽하지는 않습니다. 과거에 사람들이 IP 스푸핑은 DDoS 공격에만 적합하다고 주장하는 것을 들었습니다. 대부분의 경우 공격자는 응답을 받을 수 없고 따라서 유용한 작업을 수행할 수 없기 때문입니다.

우리가 연결하고 있는 시스템에 대해 생각해 보십시오. 귀중한 데이터를 성실하게 생성/업데이트/파괴하지 않는 실행 후 잊어버리는 API 호출이 전혀 없다고 얼마나 확신하십니까? 우수한 보안은 단순히 데이터 노출을 방지하는 것 이상으로 데이터를 보호하고 무결성을 보장하는 것이기도 합니다.

주요 금융 기관과 같은 중요한 목표인 경우 공격자는 이와 같은 접근 방식을 사용하여 MitM 공격을 시작하고 통신 흐름을 가로챌 동기가 있습니다. 귀하의 고객과 잠재 고객이 가치 있는 목표라면 귀하도 가치 있는 목표가 됩니다.

VPN(가상 사설망)

VPN은 직원이 사무실 밖에 있을 때 "회사 네트워크"에 연결할 수 있도록 하는 많은 회사의 일반적인 솔루션입니다. 또한 다른 시스템이 기존 네트워크에 연결할 수 있도록 하는 데에도 사용됩니다.

여기서 말하는 사용 사례는 다릅니다. 이는 SaaS 제품과 고객이라는 두 개의 개별 회사가 서로 통신할 수 있도록 허용하는 것입니다.

이러한 경우 대부분의 경우 연결의 각 끝에는 서로 통신할 수 있는 시스템이 하나만 있습니다. 대신, 우리는 전체 네트워크를 연결하도록 설계된 도구를 찾습니다. 이는 한 회사의 라우터에서 다른 회사의 라우터로 가상 패치 리드를 실행하는 것과 같습니다.

제가 여러분에게 프로덕션 환경의 케이블을 다른 회사의 프로덕션 환경에 직접 연결하기 위해 물리적인 버전을 요청하면 아마도 잠시 멈추실 것입니다. 많은 일시 중지. 그리고 그럴 만한 이유가 있습니다. 그러나 VPN은 "가상" 및 "비공개"이며 매우 쉽고(케이블 연결에 비해) 어디에나 존재하기 때문에 그다지 고려하지 않습니다.

각 네트워크에서 하나만 연결하기만 하면 되는 작업이라면 매우 정확한 작업을 위해 매우 무딘 도구를 사용한 것입니다.

VPN을 사용하여 정확한 작업을 계속 수행할 수 있지만, 각 네트워크에서 열고 싶은 문으로만 모든 문을 닫을 수 있도록 보장해야 하는 네트워크 수준 제어 및 라우팅 규칙 계층이 있습니다. 이는 우리가 설계된 목적에 맞는 훌륭한 도구와 접근 방식을 갖고 있음을 보여주는 또 다른 예입니다. 그러나 우리는 이를 사용하여 우리의 진화된 요구 사항에 맞게 작동하도록 하는 방법에 점진적인 단계를 만들고 있습니다.

이를 안전하게 수행한다는 것은 더 복잡하게 계층화하고 모든 계층의 모든 세부 사항을 항상 올바르게 얻을 수 있기를 바라는 것을 의미합니다. 잘못하면 원래 의도를 넘어서 전이적 액세스가 발생할 위험이 있습니다.

네트워크를 신뢰할 수 없습니다

보안 프로그램에 얼마나 많은 시간, 사람, 돈을 투자하더라도 네트워크는 쉽게 악용될 수 있는 보안 허점에 거의 확실히 노출되어 있다고 말하면 어떻게 될까요? …

업계 데이터에 따르면 세계 최대 규모의 기업 중 1% 미만만이 새롭게 등장하는 위협으로부터 네트워크를 보호하기 위한 조치를 아직 취하지 않은 것으로 나타났습니다.

역사는 옳은 일이 가장 쉬운 일이어야 한다고 가르쳐 왔습니다. 이는 소프트웨어 개발자에게 특히 중요하며 의도적인 악성 구성 요소로부터 보호합니다. 보안 기술의 이러한 느린 채택 곡선은 악의적인 행위자가 사이버 범죄의 잠재력을 확인하고 혁신하며 눈부신 성장을 주도할 수 있도록 효과적으로 지원했습니다.

— 미첼 존슨 , Sonatype

이러한 각 접근 방식의 문제점은 안전하다고 가정하려면 많은 추가 가정이 필요하다는 것입니다. 즉, 인터넷의 어느 누구도 사용자를 손상시키려고 하지 않을 것이며, 요청의 소스 IP를 신뢰할 수 있으며, 원격 네트워크는 좋은 행위자로만 구성되어 있다는 것입니다. , 이러한 가정은 현재와 미래에도 계속해서 사실 일 것입니다... 그리고 이러한 모든 가정은 귀하가 연결한 모든 네트워크, 그들이 연결한 모든 네트워크 및 모든 네트워크에도 적용됩니다...

ACME Corp의 관점에서 보면 다음과 같습니다.

이제 서로 연결된 두 개의 네트워크와 두 개의 회사 가 아닙니다. 그것은 많은 네트워크입니다. 각 SaaS 공급업체는 이를 더욱 확대하는 자체 서비스 세트를 보유하게 됩니다. 네트워크를 신뢰할 수 없을 뿐만 아니라 다른 사람의 네트워크도 신뢰할 수 없습니다. 이 그림의 모든 참가자는 네트워크를 통해 해당 위험을 전송하지 못하는 네트워크 구성이 잘못되었거나 종속성이 손상된 것일 뿐입니다.

그리고 이 사진은 이 문제의 프랙탈을 가장 확대한 예입니다! 축소하면 각 공급업체는 자체 고객, 자체 공급업체, 고객과 연결됩니다. 위험 노출 영역은 기하급수적으로 늘어납니다.

그럼 해결해 봅시다!

몇 분 안에 제품에 보안 기능을 추가할 수 있습니다! 보다 집중적이고 세분화된 솔루션을 제공하여 보안 수준을 높이겠습니다. 또한 우리는 ACME Corp과 같은 고객에게 네트워크 수준 변경을 요청함으로써 문제를 더 이상 제기하지 않을 것입니다.

대신, 우리는 보안 연결을 애플리케이션 수준 문제로 전환하고 Initech 플랫폼을 필요한 특정 위치로 확장하여 전체적인 제품 경험을 제공할 것입니다.

여기의 예에서는 Initech Platform이 ACME Corp에서 관리하는 자체 호스팅 GitHub Enterprise 서버에 대한 연결을 설정하는 방법을 안내합니다. 최종 결과는 다음과 같습니다.

필요한 모든 조각을 회전시키는 데 몇 분 밖에 걸리지 않습니다! 이를 수행하는 방법을 알아보려면 자체 호스팅 에이전트의 기반 구축을 위한 코드 둘러 보기를 살펴보세요.