코드 시리즈로 보안 인프라를 정복 코더: 암호의 일반 텍스트 스토리지
보안 인프라를 자체 조직에서 코드로 배포할 때 어떻게 하고 있습니까? 다소 학습 곡선일 수 있지만 로프를 배우는 것은 기술을 평준화하고 동료들 사이에서 두드러지며 더 많은 최종 사용자 데이터를 안전하게 유지할 수 있는 좋은 기회가 될 것입니다.
최신 코더 정복 보안 시리즈의 다음 장에서 시작하기 전에 중요한 데이터 저장소 취약점에 대한 게임화된 과제를 해결하도록 초대하고 싶습니다. 지금 플레이하고 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 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼.
마티아스 마두, Ph.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
블로그에서 최신 보안 코딩 인사이트에 대해 자세히 알아보세요.
Atlassian의 광범위한 리소스 라이브러리는 안전한 코딩 숙련도를 확보하기 위한 인적 접근 방식을 강화하는 것을 목표로 합니다.
개발자 중심 보안에 대한 최신 연구 보기
광범위한 리소스 라이브러리에는 개발자 중심의 보안 코딩을 시작하는 데 도움이 되는 백서부터 웨비나까지 유용한 리소스가 가득합니다. 지금 살펴보세요.
코드 시리즈로 보안 인프라를 정복 코더: 암호의 일반 텍스트 스토리지
보안 인프라를 자체 조직에서 코드로 배포할 때 어떻게 하고 있습니까? 다소 학습 곡선일 수 있지만 로프를 배우는 것은 기술을 평준화하고 동료들 사이에서 두드러지며 더 많은 최종 사용자 데이터를 안전하게 유지할 수 있는 좋은 기회가 될 것입니다.
최신 코더 정복 보안 시리즈의 다음 장에서 시작하기 전에 중요한 데이터 저장소 취약점에 대한 게임화된 과제를 해결하도록 초대하고 싶습니다. 지금 플레이하고 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 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼.
