김대웅 플래티어 IDT부문 책임

2. ID 기반의 접근관리

먼저 사용자 클라우드에서 운영되는 응용 프로그램에 대한 ‘식별’ 과 ‘보호’ 부분에 대해 살펴보자.

먼저 식별이 필요한 자산은 보통 응용 프로그램에서 사용되는 보호가 필요한 모든 정보에 해당하며 이런 정보들을 보호하기 위해서 사용자별 접근 제어를 제공해야 한다.

그리고 그것은 보안의 기준을 네트워크가 아닌 ‘ID’에 두는 것에서 시작한다. 왜냐하면 복잡한 방화벽 규칙과 빈번한 업데이트가 필요한 IP 주소와 달리 ‘ID’는 응용 프로그램에 연결된 사람이나 시스템에 매겨지는 고유성과 독립성을 띄기 때문이다.

이를 확인할 수 있는 좋은 예는 클라우드 제공자의 ID 기반 보안관리 서비스이다. 예를 들어 AWS 에서는 클라우드에 접속을 시도하는 ID 가 정상적인 사용자인지 확인하기 위해 ID 및 비밀번호 외에 추가인증을 요구하는 MFA⁹ 인증방식을 수행하며, 사용자는 로그인 후에 ID에 부여된 정책에 따라 특정 인프라와 기능에만 접근할 수 있다. 이것이 바로 접근관리 Access Management, AM 솔루션이며, 이는 우리가 익히 알고 있는 서비스인 ‘IAM (ID+AM)’ 이다.

이런 서비스는 대표적으로 AWS IAM, Azure AD, GCP IAM 등이 있으며, 프라이빗 클라우드를 운영하는 경우는 Active Directory나 LDAP Lightweight Directory Access Protocol 와 연계하여 사용자 ID 인증에 대한 부분을 수행하고 있다.

9. MFA(Multi Factor Authentication)는 로그인 프로세스에 보호 계층을 추가하여 계정이나 앱에 액세스할 때 사용자가 지문 스캔, 전화로 받은 코드 입력 등과 같은 추가 ID 확인을 수행하는 다단계 인증 방식이다.

이와 마찬가지로 클라우드 환경에서 사용되는 응용 프로그램은 먼저 보호가 필요한 정보를 구분하고 저장해야 하며, 클라우드에서 제공하는 IAM 시스템과 연계하여 이를 기준으로 해당 정보에 대한 접근 권한을 줄 수 있어야 한다.

그리고 응용 프로그램에 대한 효율적인 접근 권한 관리를 위해서 두 가지 사항을 고려하면 좋은데, 그 첫 번째는 접근 주체를 잘 파악하는 것이다.

접근 주체가 ‘사람’일 경우, 일반적으로 자격증명이 오래 지속되고 보관된다. 하지만 접근 주체가 ‘시스템(서버·애플리케이션· 마이크로서비스·스크립트 등)’인 경우, 접근 방식에 따라 굉장히 많은 ID가 생성될 수 있으므로, 동적으로 임시 자격증명에 해당하는 ID를 만들어 필요한 최소한의 권한만 부여하고, 작업이 끝나거나 TTL Time to Live 설정이 만료되면 사용한 ID를 삭제하는 프로세스가 필요하다.

두 번째 고려사항은 사용자별 ID 관리 체계와 보호가 필요한 데이터 관리 체계의 통합이다.

단일 클라우드 환경에서 멀티 클라우드 혹은 하이브리드 클라우드 환경으로 바뀌거나, 사용하는 클라우드 제공자가 변경되더라도 사용자는 기존에 액세스가 가능했던 정보에 그대로 액세스할 수 있어야 한다.

이와 같은 고려사항들을 응용 프로그램 내에서 모두 수행하는 것은 상당한 노력이 필요하다. 이에 응용 프로그램은 보안이 필요한 정보를 보관할 수 있고, 멀티 클라우드 환경에서의 통합된 자격증명을 지원하는 도구와 연계하는 것이 효율적일 수 있다.

예를 들어 하시코프의 Vault는 멀티 클라우드 환경에서 응용 프로그램의 ID 기반 자격증명 관리를 위해 사용할 수 있는 대표적인 솔루션이다. Vault는 LDAP, AD 혹은 클라우드 제공자의 IAM 제품 자격증명과 연동하여 임시 자격 증명을 발급해주거나, 애플리케이션에 대한 액세스를 제어할 수 있다.

3. 시크릿 관리

이와 같이 멀티 클라우드 환경에서 통합된 정보 관리 체계 및 ID 기반의 자격증명 체계가 마련되었다면, 자산으로 식별된 ▲ 기존에 보안 처리가 되지 않은 액세스 자격 증명, ▲ 하드 코딩 된 호스트명이나 방화벽 규칙, ▲ 스크립트·구성파일·소스코드에 포함된 암호화되지 않은 사용자 이름/암호/API 키, ▲ 파일 시스템에 저장된 인증서/암호화 키와 같이 보안이 필요한 정보 보호를 고려해야 한다.

이러한 정보를 보통 ‘시크릿’이라 하는데, 시크릿은 운영, 테스트, 배포, 외부 프로그램 등을 사용할 때 지속적으로 발생하게 되므로 클라우드의 암호화 서비스 혹은 외부 도구를 통해 정보를 암호화하여 저장되어야 한다.

이러한 클라우드 암호화 서비스로는 아마존의 AWS Secret Manager 와 KMS, 구글 클라우드의 Cloud HSM 및 EKM, 애저의 Key Vault가 있으며, 암호화 외부 서비스로는 하시코프의 Vault 같은 제품이 있다. 이런 서비스와 제품은 암호화 키 배포와 관리 메커니즘을 API 기반으로 제공하고 있어 응용 프로그램과의 연계가 어렵지 않다.

CNCF ¹⁰ 리포트에 따르면, 많은 기업들이 사내 솔루션을 만들고 유지하는 것보다 시크릿 관리를 아웃소싱하는 방식을 선호하고 있다. 이들은 현재 시크릿 관리를 위해 하시코프Vault를 가장 많이 사용 중이며, Vault를 도입하는 주된 이유는 클라우드에 종속되지 않는 방식으로 시크릿 관리를 다룰 수 있기 때문인 것으로 드러났다. (CNCF, 2021)

10. Cloud Native Computing Foundation(CNCF) : 컨테이너 기술을 발전시키고 기술 산업을 진화에 맞춰 조정할 수 있도록 지원하기 위해 2015년에 설립된 Linux Foundation 단체이다.

이러한 시크릿 관리에 대한 영역은 여러 부분이 있는데 이중 몇 가지 중요한 사항을 기술하면 아래와 같다.

1. 암호화 키 관리

2. 세분화된 정책을 통한 시크릿 접근제어

3. 다양한 타입의 시크릿을 관리

4. 시크릿을 중앙 집중식으로 관리

5. EaaS를 통한 암호화 관리

1) 암호화 키 관리

보안이 필수인 정보들은 반드시 암호화한 다음 저장해야 스토리지 해킹을 당하더라도 키, 암호, 인증서 및 암호화 키에 대한 액세스를 엄격하게 제어함으로써 시크릿 정보를 읽을 수 없도록 방지할 수 있다.

이런 암호화 키를 관리하기 위한 전통적인 HSM Hardware Security Module 장비는 온프레미스 환경에는 적합할 수 있지만 하이브리드, 멀티 클라우드 확장에는 유연하게 대응하기 어려우며 멀티 클라우드를 고려한다면 클라우드 기반 키 관리 방안을 찾아야 한다.

예를 들어 하시코프 Vault는 시크릿이 스토리지에 저장되기 전에 암호화 키를 통해 자동으로 암호화하는데, 이 암호화된 키를 보호하기 위한 수단으로 마스터 키를 사용하여 이중 잠금을 한다. 마스터 키는 봉인 해제 unseal 과정을 거쳐야 생성할 수 있는데 Vault를 설정 없이 디폴트로 사용하는 경우, 샤미르 공유 알고리즘 Shamir's Secret Sharing¹¹ 을 적용하여 마스터 키를 공유 수로 분해하고, 여러 사용자가 초기화 한계 threshold 수 이상을 입력하면 마스터 키가 생성되도록 하여 마스터 키를 보호하고 있다.

11. Shamir's Secret Sharing (SSS)는 분산적인 방법으로 시크릿을 보호하기 위해 사용되며, 시크릿을 공유 수로 분해하고 이 공유들은 원래의 시크릿을 재구성하는데 사용된다. 다른 암호화 키를 보호하기 위해 가장 많이 활용된다.

다만 샤미르 키 공유 방식은 관리자가 부재중일 때에는 사용하기 어려울 수 있으므로 Vault에서는 클라우드 자동 봉인해제 Cloud Auth Unseal 기능을 제공하고 있다. 이 방식은 아래 그림과 같이 마스터키를 공유수로 분해하지 않고 생성한 다음, 클라우드의 KMS 서비스에서 생성한 키로 암호화한 후, Vault에 연결된 스토리지에 마스터키를 저장하여 사용하는 구조다.

이렇게 활성화된 마스터 키로 시크릿 액세스용 암호화 키를 복호화 할 수 있게 되며, 이때 Vault는 얻어낸 암호화 키를 스토리지에 저장하지 않고 휘발성인 메모리에 저장하여 사용하기 때문에 해커는 이 암호화 키를 탈취하여 사용할 수 없게 된다.

2) 세분화된 정책을 통한 시크릿 접근제어

저장된 시크릿 정보는 사용 권한이 있는 사용자에게만 액세스 가능해야 하며, 항상 최소 권한의 원칙을 지켜 권한을 부여할 수 있도록 세분화된 정책을 제공해야 한다.

예를 들어 Vault는 사용자 인증 후 토큰을 발행하는데, 발행된 토큰은 일종의 쿠키라고 볼 수 있다. 사용자가 발행된 토큰으로 Vault에 액세스 하면, 인증 메서드가 토큰의 액세스 정책을 반환하며 토큰은 반환된 정책을 기준으로 시크릿에 대한 액세스를 제어한다. Vault의 디폴트 정책은 ‘거부’ deny by defaul¹² 로 설정되어 있기 때문에 관리자가 정책을 바탕으로 적절한 권한을 부여하지 않는다면, 어떠한 시크릿에도 액세스가 불가능하다. 또한 토큰과 정책의 연계는 토큰 발행 시간에 이뤄지기 때문에 로그인 이후 정책을 수정하더라도 이미 발급된 토큰에는 정책 권한이 부여되지 않고 이전에 발행된 권한만 가진다. 기존 토큰의 권한을 업데이트하려면, 업데이트 API를 통해 토큰에 정책 권한을 업데이트 해야 하는 등 굉장히 엄격한 관리 체계를 가지고 있다. Vault에서 제공하는 정책은 아래와 같이 시크릿이 저장된 경로를 기반으로 설정되고 최소 권한을 경로별로 설정할 수 있다.

12. Deny by default는 일종의 화이트리스트로, 명시적으로 허용되지 않는 모든 규칙을 거부하는 최소 권한의 원칙을 위한 기본 조건이다.

이와 유사하게AWS Secrets Manager¹³ 에서는 세분화된 IAM 정책 및 리소스 기반 정책을 토대로 보안 정보에 대한 액세스를 관리할 수 있다. 또한, AWS의 여러 서비스와 통합하여 사용 가능하다.

아래 예시를 통해 AWS Secret Manger에 데이터베이스 자격 증명을 저장한 후, 해당 데이터베이스에 액세스하기 위해 응용 프로그램에서 자격 증명을 사용하는 방식을 확인해볼 수 있다.

13. AWS Secrets Manager는 AWS Key Management Service(AWS KMS)를 사용하여 보안 암호의 보호되는 텍스트를 암호화한다. 여러 AWS 서비스에서 키 저장 및 암호화에 AWS KMS를 사용하며 AWS KMS는 유휴 시 보안 암호의 보안 암호화를 지원한다.