코드 시리즈로 보안 인프라를 정복 코더: 암호의 일반 텍스트 스토리지

보안 인프라를 자체 조직에서 코드로 배포할 때 어떻게 하고 있습니까? 다소 학습 곡선일 수 있지만 로프를 배우는 것은 기술을 평준화하고 동료들 사이에서 두드러지며 더 많은 최종 사용자 데이터를 안전하게 유지할 수 있는 좋은 기회가 될 것입니다.

최신 코더 정복 보안 시리즈의 다음 장에서 시작하기 전에 중요한 데이터 저장소 취약점에 대한 게임화된 과제를 해결하도록 초대하고 싶습니다. 지금 플레이하고 Kubernetes, 테라폼, Ansible, Docker 또는 CloudFormation 중에서 선택합니다.

어땠나요? 지식에 몇 가지 작업이 필요한 경우 다음을 읽으십시오.

요즘 대부분의 컴퓨터 보안의 핵심은 암호입니다. 이중 인증 또는 생체 인식과 같은 다른 보안 방법이 사용되더라도 대부분의 조직은 여전히 암호 기반 보안을 보호의 하나로 사용합니다. 많은 회사에서 암호만 사용됩니다.

우리는 암호를 너무 많이 사용하므로 암호를 만드는 방법에 대한 규칙도 있습니다. 이것은 그들을 무자비한 힘 공격이나 야생 추측에 덜 취약하게 하기 위한 것입니다. 물론, 어떤 사람들은 여전히 약한 암호를 사용, NordPass에서최근 보고서에서 입증. 2020년에도 사람들은 여전히 12345를 사용하고 있으며 초콜릿, 암호 및 하나님과 같은 다른 추측 할 수있는 단어의 무리를 사용하여 가장 민감한 자산을 보호하고 있다고 믿기 어렵다.

강력한 암호를 사용하는 데 신경 쓰지 않는 사람들이 항상 있지만 대부분의 전문 조직에서는 사용자가 액세스 단어 나 구를 특정 방식으로 만들도록 강요할 것입니다. 우리 모두는 암호가 적어도 8 자여야하고 적어도 하나의 숫자와 필요한 특별한 문자와 자본 및 소문자로 구성된 지금규칙을 알고있다.

나쁜 점은 사용자가 가장 강력한 종류의 암호를 만들기위한 규칙을 준수하더라도 모든 암호에 저장된 경우 좋지 않을 수 있다는 것입니다. 암호 12345 너트53만큼 나쁘다! 해커가 전체 암호 파일을 읽을 수 있는 경우 SpiKe&Dog12.

암호를 일반 텍스트로 저장하는 것은 왜 위험합니까?

시스템과 사용자 모두를 위험에 빠뜨리기 때문에 암호를 일반 텍스트로 저장하는 것은 나쁜 것입니다. 물론 해커가 시스템에 액세스하는 데 사용되는 모든 단일 암호를 찾고 읽을 수 있는 것은 재앙이 될 것입니다. 관리자 자격 증명이 있는 사용자를 찾고 전체 시스템 또는 사이트를 손상시킬 수 있습니다. 그리고 적절한 사용자 이름과 암호를 활용하기 때문에 내부 보안은 침입을 포착하거나 손상이 완료된 후 오래 걸지 않을 수 있습니다.

많은 사람들이 암호를 재사용하기 때문에 공격자가 일반 텍스트에 저장된 암호를 쉽게 훔칠 수 있도록하면 사용자에게도 피해를 줍니다. 암호를 만들기가 너무 어려웠기 때문에 많은 사람들이 여러 사이트에서 기억할 수 있는 암호를 재사용하는 데 의존합니다. 공격자가 암호 파일을 손상시키면 동일한 이름과 암호를 사용하여 다른 시스템에 액세스하려고 시도하므로 사용자가 보조 범죄의 큰 위험에 처하게 됩니다.

실수로 암호를 일반 텍스트에 저장하거나 이것이 도로 에서 큰 문제를 일으킬 수 있다는 것을 깨닫지 못하는 것은 비교적 쉽습니다. 예를 들어 테라폼 템플릿을 사용하여 AWS 리소스를 정의할 때 암호를 저장하는 데 사용되는 일반적인 방법입니다.

리소스 "aws_db_instance" "기본값" {
엔진 = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
사용자 이름 = "관리자"
암호 = "s3.cr3t.admin.p2sss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

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

암호 보호는 프레임워크에 따라 다르지만 모든 플랫폼에 대한 보호 방법이 존재합니다. 예를 들어 MySQL 암호는 AWS 비밀 관리자와 같은 보안 저장소에 저장할 수 있습니다.

리소스 "aws_db_instance" "기본값" {
엔진 = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
사용자 이름 = "관리자"
암호 = "${data.aws_secretsmanager_secret_version.암호.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

이 예제에서는 Terraform 템플릿이 AWS 비밀 관리자 서비스에서 암호를 받게 되며 템플릿 파일에 일반 텍스트로 저장되지 않습니다.

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

암호는 왕국의 열쇠이며 일반 텍스트에 저장해서는 안됩니다. 조직에 내부도 암호의 큰, 보호되지 않은 저장소에 액세스 할 수 없습니다, 도이 허용 비즈니스 프로토콜이어야한다 (암호화 된 자격 증명이 요즘 공유 할 수 있도록 암호 관리자의 많음이있다 - 변명!). 또한 악의적인 내부자가 파일을 스누핑하고 액세스하지 말아야 할 곳에 액세스할 위험이 있습니다.

외부 공격을 통해 SQL 주입 취약점과 같은 간단한 것을 통해 데이터베이스에 대한 백도어가 발견되고 암호가 저장되는 디렉터리에 액세스 할 수 있는 이중 whammy를 상상해보십시오. 이것이 너무 많은 오류가 있는 단계가 결실을 맺을 수 있다고 생각하십니까? 슬프게도,이 정확한 시나리오는 소니의 2011 위반에서일어났다. 백만 개 이상의 고객 암호가 일반 텍스트에 저장되었고 Lulzsec 해킹 그룹은 일반적인 SQL 주입 공격을 통해 이 암호에 액세스했습니다.

모든 암호는 지원 프레임워크 내에서 사용할 수 있는 모든 방어에 의해 보호되어야 합니다. 테라폼의 경우 암호는 템플릿 파일에 저장해서는 안 됩니다. 인프라 공급자에 따라 AWS 비밀 관리자 또는 Azure Key Vault와 같은 보안 저장소를 사용하는 것이 좋습니다.

사용자가 보안 암호를 만들도록 강요하는 것은 좋은 생각이지만 백엔드에서도 역할을 수행해야 합니다. 일반 텍스트 저장소에서 암호를 유지 하면 사용자와 시스템을 보호 하는 먼 길을 갈 것 이다. 일반 텍스트 암호 저장의 주요 위험은 가난한 액세스 제어입니다; 본질적으로, 누구나 볼 수 있습니다. 특히 갑자기 더 많은 사람들이 민감한 정보에 액세스할 수 있는 IaC 환경에서는 적절하게 해시되고 액세스가 절대적으로 필요한 사람들만 허용해야 합니다.

체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함 및 취약점의 파괴로부터 조직과 고객을 보호하는 방법. 또한 데모 IaC 챌린지를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼.