#시리즈로 보안 인프라를 정복한 코더 시리즈: 암호의 일반 텍스트 저장

보안 인프라를 자체 조직에 코드로 배포하는 데 있어 어떻게 하고 계신가요?배우는 데 다소 시간이 걸릴 수도 있지만, 요령을 익히면 기술을 한 단계 업그레이드하고 동료들 사이에서 두각을 드러낼 수 있는 좋은 기회가 될 것입니다. 과 더 많은 최종 사용자 데이터를 안전하게 보호하세요.

최신 Coders Conquer Security 시리즈의 다음 장을 시작하기 전에 민감한 데이터 스토리지 취약점에 대한 게임화된 챌린지를 플레이해 보도록 초대합니다. 지금 플레이하고 쿠버네티스, 테라폼, 앤서블, 도커 또는 클라우드포메이션 중에서 선택하세요.

어땠어요?지식을 익혀야 한다면 다음을 읽어보세요.

오늘날 대부분의 컴퓨터 보안의 핵심은 암호입니다.2단계 인증이나 생체 인식과 같은 다른 보안 방법을 사용하더라도 대부분의 조직은 여전히 암호 기반 보안을 보호의 한 요소로 사용합니다.대부분의 기업에서는 암호를 독점적으로 사용합니다.

우리는 암호를 너무 많이 사용하기 때문에 암호를 만드는 방법에 대한 규칙도 있습니다.이렇게 하면 무차별 대입 공격이나 심지어는 엉뚱한 추측에 덜 취약해질 수 있습니다.물론 최근의 사례에서 알 수 있듯이 일부 사람들은 여전히 취약한 암호를 사용합니다. 노드패스의 보고서.2020년에도 사람들이 가장 민감한 자산을 보호하기 위해 12345뿐만 아니라 초콜릿, 암호, 신과 같은 추측할 수 있는 단어를 많이 사용하고 있다는 사실이 믿기지 않습니다.

강력한 암호를 사용하는 데 신경 쓰지 않는 사람들은 항상 있을 것입니다. 하지만 대부분의 전문 조직에서는 사용자에게 특정한 방식으로 액세스 단어나 문구를 만들도록 강요합니다.지금쯤이면 암호가 8자 이상이어야 하고 대문자와 소문자로 구성되어야 하며 하나 이상의 숫자와 특수 문자가 필요한 규칙을 알고 계실 것입니다.

나쁜 점은 사용자가 가장 강력한 종류의 암호를 만드는 규칙을 준수하더라도 모든 암호가 일반 텍스트로 저장되면 아무 소용이 없을 수 있다는 것입니다.비밀번호 12345도 Nuts53만큼 나쁘다!해커가 전체 비밀번호 파일을 읽을 수 있다면 Spike&dog12.

암호를 일반 텍스트로 저장하는 것이 왜 위험한가요?

암호를 일반 텍스트로 저장하는 것은 시스템과 사용자 모두를 위험에 빠뜨리기 때문에 좋지 않습니다.해커가 시스템에 액세스하는 데 사용되는 모든 암호를 찾아서 읽을 수 있게 하는 것은 큰 재앙이 될 것이 분명합니다.단순히 관리자 자격 증명이 있는 사용자를 찾아 전체 시스템이나 사이트를 손상시킬 수도 있습니다.또한 적절한 사용자 이름과 암호를 사용하기 때문에 내부 보안 요원이 침입을 포착하지 못하거나 피해가 발생한 후 한참 후에 이를 포착하지 못할 수도 있습니다.

공격자가 일반 텍스트로 저장된 암호를 쉽게 훔칠 수 있도록 하는 것도 많은 사람들이 암호를 재사용하기 때문에 사용자에게 피해를 줍니다.우리는 암호를 만들기가 매우 어렵게 만들었기 때문에 많은 사람들이 여러 사이트에서 기억할 수 있는 암호를 재사용합니다.공격자가 암호 파일을 도용할 경우 거의 확실하게 동일한 이름과 암호를 사용하여 다른 시스템에 액세스하려고 시도하므로 사용자는 2차 범죄의 위험에 처할 수 있습니다.

실수로 암호를 일반 텍스트로 저장하거나 이로 인해 나중에 중대한 문제가 발생할 수 있다는 사실을 깨닫지 못하는 경우가 비교적 쉽습니다.예를 들어, 다음 코드는 Terraform 템플릿을 사용하여 AWS 리소스를 정의할 때 암호를 저장하는 데 사용되는 일반적인 방법입니다.

리소스 “aws_db_instance” “기본값” {
엔진 = “mysql”
할당된 스토리지 = 10
인스턴스_클래스 = “db.t2.micro”
사용자 이름 = “관리자”
비밀번호 = “s3.cr3t.admin.p2ss”
db_서브넷_그룹_이름 = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

이 예시에서는 AWS에서 MySQL 데이터베이스 인스턴스를 관리하는 데 사용되는 암호가 일반 텍스트로 저장되고 있습니다.즉, 소스 코드 리포지토리에 액세스할 수 있는 사람은 누구나 해당 리포지토리를 읽거나 복사할 수 있습니다.

암호 보호는 프레임워크에 따라 다르지만 모든 플랫폼에 대한 보호 방법이 있습니다.예를 들어 MySQL 암호는 AWS Secrets Manager와 같은 보안 스토리지에 저장할 수 있습니다.

리소스 “aws_db_instance” “기본값” {
엔진 = “mysql”
할당된 스토리지 = 10
인스턴스_클래스 = “db.t2.micro”
사용자 이름 = “관리자”
비밀번호 = “$ {data.aws_secretsmanager_secret_version.password.secret_string}”
db_서브넷_그룹_이름 = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

이 예제에서 Terraform 템플릿은 AWS Secrets Manager 서비스에서 암호를 가져오며 템플릿 파일에 일반 텍스트로 저장되지 않습니다.

일반 텍스트 저장을 피하여 암호 보호

비밀번호는 왕국의 열쇠이므로 절대 일반 텍스트로 저장해서는 안 됩니다.조직 내부에서도 보호되지 않는 대규모 암호 저장소에 액세스해서는 안 되며, 이것이 비즈니스 프로토콜로 받아들여서는 안 됩니다 (요즘에는 암호화된 자격 증명 공유를 허용하는 암호 관리자가 많이 있습니다. 변명의 여지가 없습니다!).또한 악의적인 내부자가 파일을 스누핑하여 액세스할 수 없는 곳에 액세스할 위험도 있습니다.

외부 공격의 경우 SQL 인젝션 취약점과 같은 단순한 취약점을 통해 데이터베이스의 백도어가 발견되어 암호가 저장된 디렉터리에 대한 액세스 권한도 얻게 되면 발생할 수 있는 이중 문제를 상상해 보십시오.이 단계가 너무 많아서 결실을 맺을 수 없다고 생각하시나요?안타깝게도 바로 이 시나리오가 에서 일어났습니다. 2011년 소니의 보안 침해.백만 개 이상의 고객 암호가 일반 텍스트로 저장되었으며 Lulzsec 해킹 그룹은 일반적인 SQL 삽입 공격을 통해 이러한 암호와 그 이상의 암호에 액세스했습니다.

모든 암호는 지원 프레임워크 내에서 가능한 모든 방어 수단을 통해 보호되어야 합니다.Terraform의 경우 비밀번호를 템플릿 파일에 저장해서는 안 됩니다.인프라 공급자에 따라 AWS Secrets Manager 또는 Azure Key Vault와 같은 보안 스토리지를 사용하는 것이 좋습니다.

사용자에게 보안 암호를 생성하도록 강요하는 것은 좋은 생각이지만 백엔드에서도 각자의 역할을 해야 합니다.암호를 일반 텍스트 저장소에 보관하지 않으면 사용자와 시스템을 보호하는 데 큰 도움이 됩니다.일반 텍스트 암호 저장의 주요 위험은 액세스 제어가 제대로 이루어지지 않아 누구나 볼 수 있다는 것입니다.특히 갑자기 더 많은 사람들이 민감한 정보에 액세스할 수 있게 된 IaC 환경에서는 암호를 적절하게 해시하고 액세스가 절대적으로 필요한 사람에게만 권한을 부여하는 것이 필수적입니다.

확인해 보세요 시큐어 코드 워리어 이 취약성에 대한 자세한 정보와 다른 보안 결함 및 취약점으로 인한 피해로부터 조직과 고객을 보호하는 방법을 알아보려면 블로그 페이지를 참조하십시오.또한 다음과 같은 방법도 있습니다. 데모 IaC 챌린지에 도전해 보세요 Secure Code Warrior 교육 플랫폼 내에서 모든 사이버 보안 기술을 연마하고 최신 상태로 유지할 수 있습니다.