코더를 위한 보안 인프라 코드(IaC) 시리즈: 비밀번호의 일반 텍스트 저장

조직 내에서 안전한 인프라를 코드로 배포하는 작업은 어떻게 진행하고 계신가요? 다소 학습 곡선이 있을 수 있지만, 차근차근 배워나가는 것은 여러분의 기술 역량을 한 단계 높이고 동료들 사이에서 두각을 나타내며, 더 나아가 최종 사용자의 데이터를 더욱 안전하게 보호할 수 있는 좋은 기회가 될 것입니다.

Coders Conquer Security 시리즈의 다음 챕터를 시작하기 전에, 민감한 데이터 저장 취약점을 다루는 게임화된 챌린지에 참여해 보세요. 지금 바로 플레이하고 Kubernetes, Terraform, Ansible, Docker, CloudFormation 중 하나를 선택해 보세요.

어떠셨나요? 지식을 더 보완해야 한다면 아래 내용을 읽어보세요.

오늘날 대부분의 컴퓨터 보안은 비밀번호를 중심으로 이루어집니다. 2단계 인증이나 생체 인식과 같은 다른 보안 방법을 사용하더라도, 대부분의 조직은 여전히 비밀번호 기반 보안을 보호의 한 요소로 활용하고 있습니다. 많은 기업에서 비밀번호만을 유일한 보안 수단으로 사용하기도 합니다.

우리는 비밀번호를 너무나 자주 사용하기 때문에 생성 규칙까지 정해두고 있습니다. 이는 무차별 대입 공격이나 단순 추측 공격에 대한 취약성을 줄이기 위한 것입니다. 물론 최근 NordPass의 보고서에서 볼 수 있듯이, 여전히 취약한 비밀번호를 사용하는 사람들이 있습니다. 2020년에도 여전히 '12345'와 같은 비밀번호나 'chocolate', 'password', 'God'처럼 쉽게 추측할 수 있는 단어를 사용하여 가장 민감한 자산을 보호하고 있다는 사실은 믿기 어렵습니다.

강력한 비밀번호를 사용하는 데 관심이 없는 사람들은 항상 존재하겠지만, 대부분의 전문 조직은 사용자에게 특정 방식에 따라 비밀번호나 문구를 생성하도록 강제합니다. 이제 우리는 비밀번호가 최소 8자 이상이어야 하며, 대문자와 소문자를 포함하고, 최소 하나의 숫자와 특수 문자가 포함되어야 한다는 규칙을 모두 알고 있습니다.

문제는 사용자가 가장 강력한 비밀번호를 만드는 규칙을 준수하더라도, 이를 일반 텍스트(plaintext)로 저장하면 아무런 소용이 없다는 점입니다. 해커가 전체 비밀번호 파일을 읽을 수 있다면 '12345'나 'Nuts53!SpiKe&Dog12'나 보안 수준은 매한가지입니다.

비밀번호를 일반 텍스트로 저장하는 것이 왜 위험할까요?

비밀번호를 일반 텍스트로 저장하는 것은 시스템과 사용자 모두를 위험에 빠뜨리기 때문에 위험합니다. 해커가 시스템 접근에 사용되는 모든 비밀번호를 찾아 읽을 수 있게 된다면 그야말로 재앙입니다. 해커는 관리자 권한을 가진 사용자를 찾아내어 시스템이나 사이트 전체를 장악할 수 있습니다. 또한, 해커가 정상적인 사용자 이름과 비밀번호를 사용하기 때문에 내부 보안 시스템이 침입을 감지하지 못하거나, 피해가 발생한 후 한참 뒤에야 알아차릴 수도 있습니다.

일반 텍스트로 저장된 비밀번호를 공격자가 쉽게 훔칠 수 있게 되면 사용자에게도 피해가 돌아갑니다. 많은 사람이 비밀번호를 재사용하기 때문입니다. 비밀번호 생성 규칙이 까다로워지면서, 기억하기 쉬운 비밀번호를 여러 사이트에서 돌려쓰는 사람들이 많아졌습니다. 공격자가 비밀번호 파일을 탈취하면 거의 확실히 같은 이름과 비밀번호를 사용하여 다른 시스템에도 접근을 시도할 것이며, 이는 사용자를 2차 범죄의 큰 위험에 노출시킵니다.

비밀번호를 실수로 일반 텍스트로 저장하거나, 이것이 나중에 큰 문제를 일으킬 수 있다는 사실을 깨닫지 못하는 것은 비교적 흔한 일입니다. 예를 들어, 다음 코드는 Terraform 템플릿을 사용하여 AWS 리소스를 정의할 때 비밀번호를 저장하는 일반적인 방법입니다:

resource "aws_db_instance" "default" {
 engine                 = "mysql"
 allocated_storage      = 10
 instance_class         = "db.t2.micro"
 username               = "admin"
 password               = "s3.cr3t.admin.p2ss"
 db_subnet_group_name   = aws_db_subnet_group.default.name
 vpc_security_group_ids = [aws_security_group.default.id]
}

위 예시에서 AWS의 MySQL 데이터베이스 인스턴스를 관리하는 데 사용되는 비밀번호가 일반 텍스트로 저장되어 있습니다. 즉, 소스 코드 저장소에 접근할 수 있는 사람이라면 누구나 이 비밀번호를 읽거나 복사할 수 있습니다.

비밀번호 보호 방식은 프레임워크마다 다르지만, 모든 플랫폼에는 보호 방법이 존재합니다. 예를 들어, MySQL 비밀번호는 AWS Secrets Manager와 같은 보안 저장소에 저장할 수 있습니다:

resource "aws_db_instance" "default" {
 engine            = "mysql"
 allocated_storage = 10
 instance_class    = "db.t2.micro"
 username          = "admin"
 password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
 db_subnet_group_name   = aws_db_subnet_group.default.name
 vpc_security_group_ids = [aws_security_group.default.id]
}

이 예시에서 Terraform 템플릿은 AWS Secrets Manager 서비스로부터 비밀번호를 가져오며, 템플릿 파일 내에 일반 텍스트로 저장되는 일은 결코 없습니다.

일반 텍스트 저장을 피하여 비밀번호 보호하기

비밀번호는 여러분의 왕국을 지키는 열쇠이며, 절대 일반 텍스트로 저장해서는 안 됩니다. 조직 내부 인원이라 할지라도 보호되지 않은 거대한 비밀번호 저장소에 접근할 수 있어서는 안 되며, 이것이 비즈니스 프로토콜로 용인되어서도 안 됩니다(요즘은 암호화된 자격 증명 공유를 지원하는 비밀번호 관리자가 많으니 핑계는 통하지 않습니다!). 또한, 악의적인 내부자가 파일을 엿보고 권한이 없는 곳에 접근할 위험도 존재합니다.

외부 공격의 경우, SQL 인젝션 취약점과 같이 단순한 경로로 데이터베이스 백도어가 발견되고, 그와 동시에 비밀번호가 저장된 디렉터리까지 접근이 허용된다면 얼마나 치명적인 이중고가 발생할지 상상해 보십시오. 이런 복잡한 과정이 실제로 일어날 리 없다고 생각하시나요? 안타깝게도 이와 똑같은 시나리오가 2011년 소니 해킹 사건에서 발생했습니다. 당시 100만 건 이상의 고객 비밀번호가 일반 텍스트로 저장되어 있었고, Lulzsec 해킹 그룹은 일반적인 SQL 인젝션 공격을 통해 해당 데이터와 그 이상의 정보에 접근했습니다.

모든 비밀번호는 지원 프레임워크 내에서 사용 가능한 보안 수단을 통해 보호되어야 합니다. Terraform의 경우, 비밀번호를 템플릿 파일에 저장해서는 안 됩니다. 인프라 제공업체에 따라 AWS Secrets Manager나 Azure Key Vault와 같은 안전한 저장소를 사용하는 것을 권장합니다.

사용자에게 강력한 비밀번호 설정을 요구하는 것도 중요하지만, 백엔드에서도 그에 상응하는 조치가 필요합니다. 비밀번호를 일반 텍스트로 저장하지 않는 것만으로도 사용자와 시스템을 크게 보호할 수 있습니다. 일반 텍스트 저장의 가장 큰 위험은 취약한 접근 제어에 있습니다. 즉, 누구나 비밀번호를 볼 수 있다는 점입니다. 특히 더 많은 사람이 민감한 정보에 접근할 수 있는 IaC 환경에서는 비밀번호를 적절히 해싱하고, 반드시 필요한 인원에게만 접근 권한을 부여하는 것이 필수적입니다.

이 취약점에 대한 자세한 정보와 조직 및 고객을 다양한 보안 위협으로부터 보호하는 방법은 Secure Code Warrior 블로그에서 확인하실 수 있습니다. 또한 IaC 챌린지 데모를 통해 Secure Code Warrior 교육 플랫폼에서 사이버 보안 기술을 꾸준히 연마하고 최신 상태로 유지해 보세요.