[WWCode공식 블로그 번역 #16] 보안 아키텍쳐의 중요성 및 구현 방법

Younjung Kang
wwcodeseoul
Published in
8 min readAug 21, 2022

본 글은 Women Who Code 공식 블로그에 게재된 글을 Women Who Code Seoul 운영진이 커뮤니티를 위해 한글로 번역 및 발행하였습니다. 원본 글은 여기에서 읽으실 수 있습니다.

저는 현재 Devrev라는 초기 단계의 회사에서 제품 아이디어와 아키텍처에 집중하고 있으며, 다양한 도메인의 소프트웨어 개발 및 아키텍처 설계 경험이 있습니다. 임베디드 시스템 전반과 모바일 및 온프레미스 인프라용 무선 주파수 시스템을 연구했으며, 이전 회사인 Nutanix에서는 보안 쪽을 담당했습니다. 현재는 애플리케이션 소프트웨어 관련 일을 하고 있으며, 과거의 다양한 경험이 있었기에 흥미로운 시각을 갖게 될 수 있었습니다.

저는 보안에 대해 생각할 때 먼저 여러 각도에서 봅니다. 가령 보안 솔루션을 개발하기 위해서 필요한 것은 무엇인지, 모든 것을 처음부터 만들 수 있는지 같은 것들 말이죠. 하지만 저는 보안 솔루션을 구축하는 데 필요한 것이 무엇인지 알고 있기 때문에, 모든 제품을 일일이 처음부터 만드는 선택을 하지는 않을 것입니다. 여러분은 고객 데이터가 손실되는 데이터 도난에 대한 뉴스 기사를 보셨을 것입니다. 고객들은 이에 대해 우려하고 있으며, 해당 회사는 분명 신용을 잃게 되었을 것입니다. 당연히 재정적 손실도 있었겠지요. 이러한 부정적인 결과를 방지하기 위해 보안은 꼭 필요합니다.

제품을 설계할 수 있는 다양한 방법이 있지만 시스템에 진입점이 있다고 가정해 보겠습니다. 그 진입점은 API 게이트웨이이며, 퍼블릭에 공개되는 유일한 부분입니다. 애플리케이션의 일부로 구축되는 서비스 및 마이크로 서비스가 있으며 게이트웨이 뒤에 있습니다. 그러면 주변에서 상호 작용을 하는 데이터베이스도 있을 것입니다. API 요청 또는 외부에서 제품으로 들어오는 다양한 외부 인터랙션이 존재할 것입니다.

제로 트러스트의 철학은 모든 것을 동일하게 취급한다는 것입니다. 우리는 외부 공격자를 큰 위협으로 간주하고 경계를 보호합니다. 그러나 실제로 시스템 내부에도 다양한 공격이 있을 수 있습니다. 누군가가 실수로 전체 시스템에 침투하여 전체 제품을 손상시키는 바이러스를 다운로드할 수도 있습니다. 동일한 방식으로 내부와 외부에서 보안 정책과 프로토콜을 적용하면 두 가지 모두를 보호할 수 있습니다.

주변부나 게이트웨이는 울타리라고 생각하면 됩니다. 여기에는 다양한 수준의 보호가 존재해야 합니다. 네트워크 액세스 제어 목록과 방화벽은 일반적으로 방어의 첫번째 단계입니다. 주변부라 일컫는 것은 일반적으로 제품의 진입점이나 제품 외부를 뜻합니다. 여기에는 액세스 제어 목록이라고 하는 몇 가지 특수한 규칙을 포함하여 네트워크 경계를 정의하며, 액세스를 허용할 항목에 대한 규칙을 작성합니다. 이는 IP주소와 서브넷을 처리해야 하기 때문에 상당히 복잡한 일이며, 결코 만만하지 않습니다.

인증은 액세스를 시도하는 사용자를 정의합니다. 그들이 누구이며, 어떤 정보에 접근하려고 하는지에 대한 것들을 파악합니다. 인증에는 다양한 방법이 있습니다. 기본 인증은 대부분의 사람들에게 익숙합니다. 사용자의 이름과 비밀번호를 입력하는 것이지요. 이를 디코딩하여 다른 시스템에 들어가거나 침입하는 방법을 알아내는 것은 상당히 쉽습니다. 만약 매개체가 실제로 암호화된 경우에는 다른 수준의 보안을 제공합니다.

베어러 토큰(Bearer Token)은 사용자 이름과 비밀번호가 한 단계 업그레이드 된 것입니다. ID 공급자 또는 OT 서버가 토큰을 생성합니다. 토큰의 소유자는 시스템에 액세스 할 수 있습니다. ID 공급자는 로그인하는 각 사용자에 대해 고유한 토큰을 생성합니다. 토큰에는 헤더, 페이로드 및 서명이 있습니다. 헤더와 페이로드에서 알고리즘을 실행하여 안전하고 유효성 검사를 할 수 있는지 확인합니다. 헤더는 토큰의 유형을 알려줍니다. 페이로드에는 사용자 정의 필드가 있을 수 있지만 일반적으로는 토큰을 발행한 사람 및 액세스를 허용하는 기간과 같은 일부 설정된 필드가 있습니다. 쉽게 디코딩할 수 있는 토큰 내에는 중요한 정보를 넣지 않아야 합니다.

인증서 기반 인증은 웹 서버가 인증 기관이라는 것을 신뢰한다는 것을 의미합니다. 우리는 DMV에서 발급한 ID를 유효한 신분 증명으로 신뢰합니다. 클라이언트는 서버와 통신하고 인증서를 수신할 때 해당 인증서를 신뢰하며, 인증서는 서버에 대한 프록시로 사용되어 클라이언트에 신원을 증명합니다.

OpenID Connect는 아마도 이 중에서 가장 최신일 것입니다. 웹 애플리케이션에 대한 요청이 실제로 리디렉션되어 작동됩니다. Google이나 Facebook을 통해 로그인하도록 리디렉션되는 화면을 예시로 생각할 수 있습니다.

사용자가 누구인지 알아내고 나면, 모든 작업을 수행할 수 있는 권한을 부여할 지 아니면 제한할지 여부를 확인해야 합니다. 그게 바로 권한 부여가 필요한 부분입니다. ID는 사용자 1 또는 사용자 2가 될 수 있습니다. 아키텍트, 개발자 또는 테스터와 같은 각각의 역할에 해당하는 사용자를 그룹화할 수 있습니다. 또한 특정 역할에 특정 정책을 적용할 수도 있습니다. 이를 일반적으로 Role-based access control(RBAC)라고 합니다. 모든 종류의 서비스 메시를 사용하여 제품을 만든 경우에는 개방형 정책 에이전트(OPA; Open Policy Agent)를 연결할 수 있습니다. 개방형 정책 에이전트 엔진에 쿼리 및 결정을 보낼 수 있습니다. 엔진은 정책을 작성하고 액세스를 허용해야 하는지 여부를 파악합니다.

내부 서비스는 어떨까요? 네트워크 측면에서 보면 마이크로 세분화(Micro-segmentation)라는 것이 있습니다. 이는 애플리케이션을 보호하는 방법입니다. 웹이 데이터베이스와 통신할 수 없다는 규칙을 작성하려는 경우 이를 통해 해당 IP 주소와 포트를 네트워크 규칙으로 변환하여 현실화할 수 있습니다. 제로 트러스트 모델은 어떤 상호작용도 허용하지 않는 것으로 시작하여 점진적으로 허용해나갑니다.

다음 규칙은 모든 통신을 암호화하는 것입니다. 모든 통신을 암호화하기 위해 상호 TLS를 구성합니다. 이 과정에서 클라이언트는 서버를 확인하고, 서버는 클라이언트를 확인합니다. 통신은 완전히 암호화되어 있습니다. 암호화의 다른 부분은 데이터 저장소에서의 암호화(Data Encryption at Rest)라고 불리는 것입니다. 이는 데이터베이스에 저장되는 데이터 또한 암호화하며, 퍼블릭 키와 프라이빗 키의 조합으로 암호화가 됩니다. 데이터베이스 보안의 또 다른 방법은 액세스 제어를 활용하는 것입니다.

코드에는 취약성이 있습니다. 많은 코드는 라이브러리의 조합일 수도 있으며, 취약점이 있는 오픈소스 코드일 수도 있습니다. 이 중에서도 가장 큰 취약성 위험을 갖는 것은 원격 코드를 실행하는 것입니다. 공격자는 실제로 서버를 통해 악성 코드나 활동을 주입할 수도 있고, 스크립트를 실행하여 시스템이나 전체 네트워크에 대한 액세스 권한을 얻어 시스템을 손상시킬 수도 있습니다.

그런 공격은 어떻게 해결해야 할까요? 지속적인 정적 코드 분석에 가까운 코드 취약성 스캔을 활용하면 됩니다. 코드의 빌드 및 배포, 테스트되는 CI/CD 파이프라인에서 라이브러리에 대한 취약성을 검색합니다. 사용 중인 바이너리 파일을 스캔할 수도 있습니다. 이러한 스캔 과정을 통해 취약성 스캔 및 보안 패치 적용 여부를 정기적으로 알 수 있습니다. 오픈소스 라이브러리의 등급을 살펴보는 것과 패치 적용 빈도 및 커뮤니티 참여와 관련하여 보안 관행을 확인하는 것도 중요합니다.

코드 취약성에 대해 할 수 있는 다른 종류의 분석은 퍼지(fuzzing)입니다. 모든 종류의 기능이나 제품 또는 서비스에 대한 입력을 결정하고, 입력 기울기를 기준으로 데이터를 생성합니다. 퍼지 데이터는 잠재적인 악성 데이터입니다. 이 데이터에 대해 테스트를 실행하고 시스템이 어떻게 동작하는지 분석합니다. 그런 다음 동작과 결함 위치를 기준으로 문제를 식별하기 시작합니다. 한 단계 더 나아가 모의 해킹(Pen-testing)이라고 불리는 것도 있습니다. 전반적인 정보를 어떻게 수집할지 목표를 설정하고, 검색 도구를 사용하여 실제로 대상이 침입에 어떻게 반응하는지 파악할 수 있습니다. 실제로 이러한 웹 애플리케이션 공격은 스스로 실행되기 때문에 이를 준비하여 취약점을 공략하는 것은 아주 중요합니다.

--

--