코더들이 보안 인프라를 코드 집합으로 장악하다: 비활성화된 보안 기능들
요즘 사이버 보안 위협은 어디에나 존재하며 끊임없이 이어집니다. 우리 삶의 더 많은 측면이 디지털화될수록 사이버 범죄자들의 위험도 커집니다: 보호해야 할 코드가 너무 많고 개인 데이터는 너무나 가치 있기 때문입니다. 그리고 프로그램이 배포된 후 공격 표면의 모든 측면을 따라잡고 방어하려는 시도는 거의 불가능해졌습니다.
이러한 증상 중 일부를 완화할 수 있는 접근법이 존재하며, 그중 하나는 선견지명이 있는 조직들이 인프라스트럭처 인 코드(IaC) 개념을 채택할 때 명확히 드러납니다. 물론 모든 개발 과정에서 그렇듯, 극복해야 할 몇 가지 보안 장애물이 존재합니다. 개발자들이 애플리케이션을 호스팅하는 데 필수적인 인프라를 생성하는 코드를 다루고 있기 때문에, 프로세스의 각 단계에서 보안에 대한 인식이 매우 중요합니다.
그렇다면 클라우드 서버 환경에서 새로 입문한 개발자는 정확히 어떻게 기술을 향상시키고, 내부 구조를 익히며, 보안 의식을 높여 구축에 임할 수 있을까요? 우리는 IaC의 가장 흔한 취약점을 다루기 위해 'Coders Conquer Security' 시리즈를 기획했으며, 향후 블로그에서는 여러분 개발자가 조직 내에서 안전한 인프라를 코드로 구현하기 시작하기 위해 취할 수 있는 조치들에 초점을 맞출 예정입니다.
시작해 보자.
미국 서부 시대에 유래한 우화가 하나 있다. 한 남자가 강도들이 자신의 집을 습격해 물건을 훔쳐갈까 봐 지나치게 불안해했다. 이를 대비해 그는 모든 종류의 보안 장치에 투자했다. 매우 튼튼한 현관문을 설치하고, 모든 창문을 막고, 손이 닿는 곳에 많은 무기를 비치해 두었다. 그런데도 어느 날 밤 그가 잠든 사이에 강도들이 쳐들어왔다. 옆문을 잠그지 않았기 때문이다. 도둑들은 단순히 보안 장치가 꺼져 있는 것을 발견하고 재빨리 그 상황을 이용했을 뿐이었다.
인프라에서 보안 기능을 비활성화하는 것은 이와 매우 유사합니다. 네트워크에 견고한 보안 인프라가 구축되어 있더라도 일부 요소가 비활성화되어 있다면 별다른 도움이 되지 않습니다.
잠시 도전 과제를 제시해 보겠습니다:
위의 링크를 방문하시면 저희 게임화 교육 플랫폼에 접속하실 수 있습니다. 지금 바로 비활성화된 보안 기능의 취약점을 제거해 보세요. (참고: Kubernetes에서 열리지만, 드롭다운 메뉴를 사용하면 Docker, CloudFormation, Terraform, Ansible 중에서 선택할 수 있습니다).
어떻게 됐어? 아직 할 일이 남아 있다면 계속 읽어봐:
보안 기능은 다양한 이유로 비활성화될 수 있습니다. 일부 애플리케이션과 프레임워크는 기본적으로 비활성화되어 있을 수 있으며, 작동하려면 먼저 활성화해야 합니다. 또한 관리자가 특정 작업을 더 쉽게 수행하기 위해 지속적인 문제나 차단 없이(예: AWS S3 버킷 공개) 특정 보안 기능을 비활성화했을 수도 있습니다. 작업이 완료된 후, 비활성화된 기능을 다시 활성화하는 것을 잊을 수도 있습니다. 또한 향후 작업을 용이하게 하기 위해 해당 기능을 계속 비활성화 상태로 유지하는 것을 선호할 수도 있습니다.
비활성화된 보안 기능이 왜 그렇게 위험한가
하나 이상의 보안 기능을 비활성화하는 것은 여러 가지 이유로 좋지 않습니다. 첫째, 해당 보안 기능은 알려진 악용, 위협 또는 취약점으로부터 인프라 자원을 보호하기 위해 포함되었습니다. 비활성화된 상태에서는 자원을 보호할 수 없습니다.
공격자들은 항상 먼저 쉽게 악용할 수 있는 취약점을 찾으려 할 것이며, 심지어 가장 흔한 약점을 분석하기 위해 스크립트를 사용할 수도 있습니다. 이는 마치 한 거리의 모든 차량을 확인하여 창문을 깨는 것보다 훨씬 쉬운 열린 문이 있는지 살펴보는 도둑과 같습니다. 해커들은 일반적인 보안 방어 체계가 작동하지 않는다는 사실을 발견하면 놀랄 것입니다. 하지만 그런 상황이 발생하면, 그들은 이를 악용하는 데 오래 걸리지 않을 것입니다.
둘째, 우수한 보안 시스템을 구축한 후 이를 비활성화하면 허위의 안전감을 조성합니다. 관리자들은 누군가가 해당 방어 체계를 비활성화했다는 사실을 모른다면 가장 흔한 위협으로부터 보호받고 있다고 생각할 수 있습니다.
공격자가 비활성화된 보안 기능을 악용할 수 있는 사례로, AWS S3의 공개 액세스 차단 보안 기능을 살펴보겠습니다. Amazon S3의 공개 액세스 차단 기능을 사용하면 계정 관리자 및 저장소 소유자가 Amazon S3 리소스에 대한 공개 액세스를 제한하기 위한 중앙 집중식 제어를 쉽게 구성할 수 있습니다. 그러나 일부 관리자는 S3 버킷 접근에 문제가 생기면 작업을 최대한 빨리 완료하기 위해 버킷을 공개하기로 결정합니다. 이 보안 기능을 활성화하는 것을 잊어버리면 공격자는 해당 S3 버킷에 저장된 정보에 대한 완전한 접근 권한을 얻게 되며, 이는 정보 유출을 초래할 뿐만 아니라 데이터 전송 비용으로 인한 추가 비용 발생으로 이어집니다.
실제 코드 몇 가지를 비교해 보겠습니다. 다음 CloudFormation 스니펫을 참조하세요:
취약:
기업용 큐브:
유형: AWS: :S3: :Bucket
속성:
공개 액세스 블록 설정:
blockPublicACLS: false
BlockPublicPolicy: false
ignorePublicacls: false
restrictPublicBuckets: false
버전 관리 설정:
상태: 활성화됨
버킷 암호화:
서버 측 암호화 설정:
- 기본 서버 측 암호화:
SSE 알고리즘: «AES256»
세구로:
기업용 큐브:
유형: AWS: :S3: :Bucket
속성:
공개 액세스 블록 설정:
BlockPublicACLS: true
BlockPublicPolicy: true
ignorePublicacls: true
RestrictPublicBuckets: true
버전 관리 설정:
상태: 활성화됨
버킷 암호화:
서버 측 암호화 설정:
- 기본 서버 측 암호화:
SSE 알고리즘: "AES256"
비활성화된 보안 기능 방지
보안 기능의 비활성화가 조직에 부정적인 영향을 미치지 않도록 하는 것은 정책과 실행 모두에 관한 문제입니다. 보안 기능은 매우 특정된 상황에서만 비활성화되어야 한다는 명확한 정책이 수립되어야 합니다. 문제 해결이나 애플리케이션 업데이트를 위해 기능을 일시적으로 비활성화해야 하는 상황은 반드시 기록되어야 합니다. 필요한 작업이 완료된 후에는 해당 기능이 완전히 재활성화되었는지 반드시 확인해야 합니다.
보안 기능을 영구적으로 비활성화하여 운영을 간소화해야 하는 경우, 해당 데이터에 대한 다른 보호 장치를 마련하여 기본 보호 기능이 없는 상태에서도 해커가 접근할 수 없도록 보장해야 합니다. 필수 보호 기능을 비활성화한 경우, 공격자가 열린 문을 발견하고 이를 악용하는 것은 시간 문제일 뿐입니다.
더 많은 정보를 얻고, 스스로에게 도전하세요:
한번 살펴보세요 Secure Code Warrior 블로그 페이지를 방문하여 이 취약점에 대한 자세한 정보와 조직 및 고객을 다른 보안 결함 및 취약점의 피해로부터 보호하는 방법을 알아보세요.
게시물을 읽으셨으니 이제 이 취약점을 찾아 수정할 준비가 되셨나요? 지금 바로 시작하세요! Secure Code Warrior 플랫폼에서iMac용 게임화된 보안 챌린지를 시도해 보세요. 사이버 보안 기술을 완벽하게 연마하고 최신 상태로 유지할 Secure Code Warrior .
이것은 코드로서의 인프라(Infrastructure as Code)의 주요 취약점 8가지를 다루는 주간 시리즈입니다. 다음 주에 더 많은 정보를 얻으러 다시 찾아오세요!
공격자들은 항상 먼저 쉽게 악용할 수 있는 취약점을 찾으려 할 것이며, 심지어 가장 흔한 약점을 분석하기 위해 스크립트를 사용할 수도 있습니다. 이는 마치 한 거리의 모든 차량을 확인하여 창문을 깨는 것보다 훨씬 쉬운 열린 문이 있는지 살펴보는 도둑과 같습니다.
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Secure Code Warrior 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.
데모 예약하기
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
요즘 사이버 보안 위협은 어디에나 존재하며 끊임없이 이어집니다. 우리 삶의 더 많은 측면이 디지털화될수록 사이버 범죄자들의 위험도 커집니다: 보호해야 할 코드가 너무 많고 개인 데이터는 너무나 가치 있기 때문입니다. 그리고 프로그램이 배포된 후 공격 표면의 모든 측면을 따라잡고 방어하려는 시도는 거의 불가능해졌습니다.
이러한 증상 중 일부를 완화할 수 있는 접근법이 존재하며, 그중 하나는 선견지명이 있는 조직들이 인프라스트럭처 인 코드(IaC) 개념을 채택할 때 명확히 드러납니다. 물론 모든 개발 과정에서 그렇듯, 극복해야 할 몇 가지 보안 장애물이 존재합니다. 개발자들이 애플리케이션을 호스팅하는 데 필수적인 인프라를 생성하는 코드를 다루고 있기 때문에, 프로세스의 각 단계에서 보안에 대한 인식이 매우 중요합니다.
그렇다면 클라우드 서버 환경에서 새로 입문한 개발자는 정확히 어떻게 기술을 향상시키고, 내부 구조를 익히며, 보안 의식을 높여 구축에 임할 수 있을까요? 우리는 IaC의 가장 흔한 취약점을 다루기 위해 'Coders Conquer Security' 시리즈를 기획했으며, 향후 블로그에서는 여러분 개발자가 조직 내에서 안전한 인프라를 코드로 구현하기 시작하기 위해 취할 수 있는 조치들에 초점을 맞출 예정입니다.
시작해 보자.
미국 서부 시대에 유래한 우화가 하나 있다. 한 남자가 강도들이 자신의 집을 습격해 물건을 훔쳐갈까 봐 지나치게 불안해했다. 이를 대비해 그는 모든 종류의 보안 장치에 투자했다. 매우 튼튼한 현관문을 설치하고, 모든 창문을 막고, 손이 닿는 곳에 많은 무기를 비치해 두었다. 그런데도 어느 날 밤 그가 잠든 사이에 강도들이 쳐들어왔다. 옆문을 잠그지 않았기 때문이다. 도둑들은 단순히 보안 장치가 꺼져 있는 것을 발견하고 재빨리 그 상황을 이용했을 뿐이었다.
인프라에서 보안 기능을 비활성화하는 것은 이와 매우 유사합니다. 네트워크에 견고한 보안 인프라가 구축되어 있더라도 일부 요소가 비활성화되어 있다면 별다른 도움이 되지 않습니다.
잠시 도전 과제를 제시해 보겠습니다:
위의 링크를 방문하시면 저희 게임화 교육 플랫폼에 접속하실 수 있습니다. 지금 바로 비활성화된 보안 기능의 취약점을 제거해 보세요. (참고: Kubernetes에서 열리지만, 드롭다운 메뉴를 사용하면 Docker, CloudFormation, Terraform, Ansible 중에서 선택할 수 있습니다).
어떻게 됐어? 아직 할 일이 남아 있다면 계속 읽어봐:
보안 기능은 다양한 이유로 비활성화될 수 있습니다. 일부 애플리케이션과 프레임워크는 기본적으로 비활성화되어 있을 수 있으며, 작동하려면 먼저 활성화해야 합니다. 또한 관리자가 특정 작업을 더 쉽게 수행하기 위해 지속적인 문제나 차단 없이(예: AWS S3 버킷 공개) 특정 보안 기능을 비활성화했을 수도 있습니다. 작업이 완료된 후, 비활성화된 기능을 다시 활성화하는 것을 잊을 수도 있습니다. 또한 향후 작업을 용이하게 하기 위해 해당 기능을 계속 비활성화 상태로 유지하는 것을 선호할 수도 있습니다.
비활성화된 보안 기능이 왜 그렇게 위험한가
하나 이상의 보안 기능을 비활성화하는 것은 여러 가지 이유로 좋지 않습니다. 첫째, 해당 보안 기능은 알려진 악용, 위협 또는 취약점으로부터 인프라 자원을 보호하기 위해 포함되었습니다. 비활성화된 상태에서는 자원을 보호할 수 없습니다.
공격자들은 항상 먼저 쉽게 악용할 수 있는 취약점을 찾으려 할 것이며, 심지어 가장 흔한 약점을 분석하기 위해 스크립트를 사용할 수도 있습니다. 이는 마치 한 거리의 모든 차량을 확인하여 창문을 깨는 것보다 훨씬 쉬운 열린 문이 있는지 살펴보는 도둑과 같습니다. 해커들은 일반적인 보안 방어 체계가 작동하지 않는다는 사실을 발견하면 놀랄 것입니다. 하지만 그런 상황이 발생하면, 그들은 이를 악용하는 데 오래 걸리지 않을 것입니다.
둘째, 우수한 보안 시스템을 구축한 후 이를 비활성화하면 허위의 안전감을 조성합니다. 관리자들은 누군가가 해당 방어 체계를 비활성화했다는 사실을 모른다면 가장 흔한 위협으로부터 보호받고 있다고 생각할 수 있습니다.
공격자가 비활성화된 보안 기능을 악용할 수 있는 사례로, AWS S3의 공개 액세스 차단 보안 기능을 살펴보겠습니다. Amazon S3의 공개 액세스 차단 기능을 사용하면 계정 관리자 및 저장소 소유자가 Amazon S3 리소스에 대한 공개 액세스를 제한하기 위한 중앙 집중식 제어를 쉽게 구성할 수 있습니다. 그러나 일부 관리자는 S3 버킷 접근에 문제가 생기면 작업을 최대한 빨리 완료하기 위해 버킷을 공개하기로 결정합니다. 이 보안 기능을 활성화하는 것을 잊어버리면 공격자는 해당 S3 버킷에 저장된 정보에 대한 완전한 접근 권한을 얻게 되며, 이는 정보 유출을 초래할 뿐만 아니라 데이터 전송 비용으로 인한 추가 비용 발생으로 이어집니다.
실제 코드 몇 가지를 비교해 보겠습니다. 다음 CloudFormation 스니펫을 참조하세요:
취약:
기업용 큐브:
유형: AWS: :S3: :Bucket
속성:
공개 액세스 블록 설정:
blockPublicACLS: false
BlockPublicPolicy: false
ignorePublicacls: false
restrictPublicBuckets: false
버전 관리 설정:
상태: 활성화됨
버킷 암호화:
서버 측 암호화 설정:
- 기본 서버 측 암호화:
SSE 알고리즘: «AES256»
세구로:
기업용 큐브:
유형: AWS: :S3: :Bucket
속성:
공개 액세스 블록 설정:
BlockPublicACLS: true
BlockPublicPolicy: true
ignorePublicacls: true
RestrictPublicBuckets: true
버전 관리 설정:
상태: 활성화됨
버킷 암호화:
서버 측 암호화 설정:
- 기본 서버 측 암호화:
SSE 알고리즘: "AES256"
비활성화된 보안 기능 방지
보안 기능의 비활성화가 조직에 부정적인 영향을 미치지 않도록 하는 것은 정책과 실행 모두에 관한 문제입니다. 보안 기능은 매우 특정된 상황에서만 비활성화되어야 한다는 명확한 정책이 수립되어야 합니다. 문제 해결이나 애플리케이션 업데이트를 위해 기능을 일시적으로 비활성화해야 하는 상황은 반드시 기록되어야 합니다. 필요한 작업이 완료된 후에는 해당 기능이 완전히 재활성화되었는지 반드시 확인해야 합니다.
보안 기능을 영구적으로 비활성화하여 운영을 간소화해야 하는 경우, 해당 데이터에 대한 다른 보호 장치를 마련하여 기본 보호 기능이 없는 상태에서도 해커가 접근할 수 없도록 보장해야 합니다. 필수 보호 기능을 비활성화한 경우, 공격자가 열린 문을 발견하고 이를 악용하는 것은 시간 문제일 뿐입니다.
더 많은 정보를 얻고, 스스로에게 도전하세요:
한번 살펴보세요 Secure Code Warrior 블로그 페이지를 방문하여 이 취약점에 대한 자세한 정보와 조직 및 고객을 다른 보안 결함 및 취약점의 피해로부터 보호하는 방법을 알아보세요.
게시물을 읽으셨으니 이제 이 취약점을 찾아 수정할 준비가 되셨나요? 지금 바로 시작하세요! Secure Code Warrior 플랫폼에서iMac용 게임화된 보안 챌린지를 시도해 보세요. 사이버 보안 기술을 완벽하게 연마하고 최신 상태로 유지할 Secure Code Warrior .
이것은 코드로서의 인프라(Infrastructure as Code)의 주요 취약점 8가지를 다루는 주간 시리즈입니다. 다음 주에 더 많은 정보를 얻으러 다시 찾아오세요!
요즘 사이버 보안 위협은 어디에나 존재하며 끊임없이 이어집니다. 우리 삶의 더 많은 측면이 디지털화될수록 사이버 범죄자들의 위험도 커집니다: 보호해야 할 코드가 너무 많고 개인 데이터는 너무나 가치 있기 때문입니다. 그리고 프로그램이 배포된 후 공격 표면의 모든 측면을 따라잡고 방어하려는 시도는 거의 불가능해졌습니다.
이러한 증상 중 일부를 완화할 수 있는 접근법이 존재하며, 그중 하나는 선견지명이 있는 조직들이 인프라스트럭처 인 코드(IaC) 개념을 채택할 때 명확히 드러납니다. 물론 모든 개발 과정에서 그렇듯, 극복해야 할 몇 가지 보안 장애물이 존재합니다. 개발자들이 애플리케이션을 호스팅하는 데 필수적인 인프라를 생성하는 코드를 다루고 있기 때문에, 프로세스의 각 단계에서 보안에 대한 인식이 매우 중요합니다.
그렇다면 클라우드 서버 환경에서 새로 입문한 개발자는 정확히 어떻게 기술을 향상시키고, 내부 구조를 익히며, 보안 의식을 높여 구축에 임할 수 있을까요? 우리는 IaC의 가장 흔한 취약점을 다루기 위해 'Coders Conquer Security' 시리즈를 기획했으며, 향후 블로그에서는 여러분 개발자가 조직 내에서 안전한 인프라를 코드로 구현하기 시작하기 위해 취할 수 있는 조치들에 초점을 맞출 예정입니다.
시작해 보자.
미국 서부 시대에 유래한 우화가 하나 있다. 한 남자가 강도들이 자신의 집을 습격해 물건을 훔쳐갈까 봐 지나치게 불안해했다. 이를 대비해 그는 모든 종류의 보안 장치에 투자했다. 매우 튼튼한 현관문을 설치하고, 모든 창문을 막고, 손이 닿는 곳에 많은 무기를 비치해 두었다. 그런데도 어느 날 밤 그가 잠든 사이에 강도들이 쳐들어왔다. 옆문을 잠그지 않았기 때문이다. 도둑들은 단순히 보안 장치가 꺼져 있는 것을 발견하고 재빨리 그 상황을 이용했을 뿐이었다.
인프라에서 보안 기능을 비활성화하는 것은 이와 매우 유사합니다. 네트워크에 견고한 보안 인프라가 구축되어 있더라도 일부 요소가 비활성화되어 있다면 별다른 도움이 되지 않습니다.
잠시 도전 과제를 제시해 보겠습니다:
위의 링크를 방문하시면 저희 게임화 교육 플랫폼에 접속하실 수 있습니다. 지금 바로 비활성화된 보안 기능의 취약점을 제거해 보세요. (참고: Kubernetes에서 열리지만, 드롭다운 메뉴를 사용하면 Docker, CloudFormation, Terraform, Ansible 중에서 선택할 수 있습니다).
어떻게 됐어? 아직 할 일이 남아 있다면 계속 읽어봐:
보안 기능은 다양한 이유로 비활성화될 수 있습니다. 일부 애플리케이션과 프레임워크는 기본적으로 비활성화되어 있을 수 있으며, 작동하려면 먼저 활성화해야 합니다. 또한 관리자가 특정 작업을 더 쉽게 수행하기 위해 지속적인 문제나 차단 없이(예: AWS S3 버킷 공개) 특정 보안 기능을 비활성화했을 수도 있습니다. 작업이 완료된 후, 비활성화된 기능을 다시 활성화하는 것을 잊을 수도 있습니다. 또한 향후 작업을 용이하게 하기 위해 해당 기능을 계속 비활성화 상태로 유지하는 것을 선호할 수도 있습니다.
비활성화된 보안 기능이 왜 그렇게 위험한가
하나 이상의 보안 기능을 비활성화하는 것은 여러 가지 이유로 좋지 않습니다. 첫째, 해당 보안 기능은 알려진 악용, 위협 또는 취약점으로부터 인프라 자원을 보호하기 위해 포함되었습니다. 비활성화된 상태에서는 자원을 보호할 수 없습니다.
공격자들은 항상 먼저 쉽게 악용할 수 있는 취약점을 찾으려 할 것이며, 심지어 가장 흔한 약점을 분석하기 위해 스크립트를 사용할 수도 있습니다. 이는 마치 한 거리의 모든 차량을 확인하여 창문을 깨는 것보다 훨씬 쉬운 열린 문이 있는지 살펴보는 도둑과 같습니다. 해커들은 일반적인 보안 방어 체계가 작동하지 않는다는 사실을 발견하면 놀랄 것입니다. 하지만 그런 상황이 발생하면, 그들은 이를 악용하는 데 오래 걸리지 않을 것입니다.
둘째, 우수한 보안 시스템을 구축한 후 이를 비활성화하면 허위의 안전감을 조성합니다. 관리자들은 누군가가 해당 방어 체계를 비활성화했다는 사실을 모른다면 가장 흔한 위협으로부터 보호받고 있다고 생각할 수 있습니다.
공격자가 비활성화된 보안 기능을 악용할 수 있는 사례로, AWS S3의 공개 액세스 차단 보안 기능을 살펴보겠습니다. Amazon S3의 공개 액세스 차단 기능을 사용하면 계정 관리자 및 저장소 소유자가 Amazon S3 리소스에 대한 공개 액세스를 제한하기 위한 중앙 집중식 제어를 쉽게 구성할 수 있습니다. 그러나 일부 관리자는 S3 버킷 접근에 문제가 생기면 작업을 최대한 빨리 완료하기 위해 버킷을 공개하기로 결정합니다. 이 보안 기능을 활성화하는 것을 잊어버리면 공격자는 해당 S3 버킷에 저장된 정보에 대한 완전한 접근 권한을 얻게 되며, 이는 정보 유출을 초래할 뿐만 아니라 데이터 전송 비용으로 인한 추가 비용 발생으로 이어집니다.
실제 코드 몇 가지를 비교해 보겠습니다. 다음 CloudFormation 스니펫을 참조하세요:
취약:
기업용 큐브:
유형: AWS: :S3: :Bucket
속성:
공개 액세스 블록 설정:
blockPublicACLS: false
BlockPublicPolicy: false
ignorePublicacls: false
restrictPublicBuckets: false
버전 관리 설정:
상태: 활성화됨
버킷 암호화:
서버 측 암호화 설정:
- 기본 서버 측 암호화:
SSE 알고리즘: «AES256»
세구로:
기업용 큐브:
유형: AWS: :S3: :Bucket
속성:
공개 액세스 블록 설정:
BlockPublicACLS: true
BlockPublicPolicy: true
ignorePublicacls: true
RestrictPublicBuckets: true
버전 관리 설정:
상태: 활성화됨
버킷 암호화:
서버 측 암호화 설정:
- 기본 서버 측 암호화:
SSE 알고리즘: "AES256"
비활성화된 보안 기능 방지
보안 기능의 비활성화가 조직에 부정적인 영향을 미치지 않도록 하는 것은 정책과 실행 모두에 관한 문제입니다. 보안 기능은 매우 특정된 상황에서만 비활성화되어야 한다는 명확한 정책이 수립되어야 합니다. 문제 해결이나 애플리케이션 업데이트를 위해 기능을 일시적으로 비활성화해야 하는 상황은 반드시 기록되어야 합니다. 필요한 작업이 완료된 후에는 해당 기능이 완전히 재활성화되었는지 반드시 확인해야 합니다.
보안 기능을 영구적으로 비활성화하여 운영을 간소화해야 하는 경우, 해당 데이터에 대한 다른 보호 장치를 마련하여 기본 보호 기능이 없는 상태에서도 해커가 접근할 수 없도록 보장해야 합니다. 필수 보호 기능을 비활성화한 경우, 공격자가 열린 문을 발견하고 이를 악용하는 것은 시간 문제일 뿐입니다.
더 많은 정보를 얻고, 스스로에게 도전하세요:
한번 살펴보세요 Secure Code Warrior 블로그 페이지를 방문하여 이 취약점에 대한 자세한 정보와 조직 및 고객을 다른 보안 결함 및 취약점의 피해로부터 보호하는 방법을 알아보세요.
게시물을 읽으셨으니 이제 이 취약점을 찾아 수정할 준비가 되셨나요? 지금 바로 시작하세요! Secure Code Warrior 플랫폼에서iMac용 게임화된 보안 챌린지를 시도해 보세요. 사이버 보안 기술을 완벽하게 연마하고 최신 상태로 유지할 Secure Code Warrior .
이것은 코드로서의 인프라(Infrastructure as Code)의 주요 취약점 8가지를 다루는 주간 시리즈입니다. 다음 주에 더 많은 정보를 얻으러 다시 찾아오세요!
아래 링크를 클릭하고 이 자료의 PDF를 다운로드하세요.
Secure Code Warrior 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.
보고서 보기데모 예약하기
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
요즘 사이버 보안 위협은 어디에나 존재하며 끊임없이 이어집니다. 우리 삶의 더 많은 측면이 디지털화될수록 사이버 범죄자들의 위험도 커집니다: 보호해야 할 코드가 너무 많고 개인 데이터는 너무나 가치 있기 때문입니다. 그리고 프로그램이 배포된 후 공격 표면의 모든 측면을 따라잡고 방어하려는 시도는 거의 불가능해졌습니다.
이러한 증상 중 일부를 완화할 수 있는 접근법이 존재하며, 그중 하나는 선견지명이 있는 조직들이 인프라스트럭처 인 코드(IaC) 개념을 채택할 때 명확히 드러납니다. 물론 모든 개발 과정에서 그렇듯, 극복해야 할 몇 가지 보안 장애물이 존재합니다. 개발자들이 애플리케이션을 호스팅하는 데 필수적인 인프라를 생성하는 코드를 다루고 있기 때문에, 프로세스의 각 단계에서 보안에 대한 인식이 매우 중요합니다.
그렇다면 클라우드 서버 환경에서 새로 입문한 개발자는 정확히 어떻게 기술을 향상시키고, 내부 구조를 익히며, 보안 의식을 높여 구축에 임할 수 있을까요? 우리는 IaC의 가장 흔한 취약점을 다루기 위해 'Coders Conquer Security' 시리즈를 기획했으며, 향후 블로그에서는 여러분 개발자가 조직 내에서 안전한 인프라를 코드로 구현하기 시작하기 위해 취할 수 있는 조치들에 초점을 맞출 예정입니다.
시작해 보자.
미국 서부 시대에 유래한 우화가 하나 있다. 한 남자가 강도들이 자신의 집을 습격해 물건을 훔쳐갈까 봐 지나치게 불안해했다. 이를 대비해 그는 모든 종류의 보안 장치에 투자했다. 매우 튼튼한 현관문을 설치하고, 모든 창문을 막고, 손이 닿는 곳에 많은 무기를 비치해 두었다. 그런데도 어느 날 밤 그가 잠든 사이에 강도들이 쳐들어왔다. 옆문을 잠그지 않았기 때문이다. 도둑들은 단순히 보안 장치가 꺼져 있는 것을 발견하고 재빨리 그 상황을 이용했을 뿐이었다.
인프라에서 보안 기능을 비활성화하는 것은 이와 매우 유사합니다. 네트워크에 견고한 보안 인프라가 구축되어 있더라도 일부 요소가 비활성화되어 있다면 별다른 도움이 되지 않습니다.
잠시 도전 과제를 제시해 보겠습니다:
위의 링크를 방문하시면 저희 게임화 교육 플랫폼에 접속하실 수 있습니다. 지금 바로 비활성화된 보안 기능의 취약점을 제거해 보세요. (참고: Kubernetes에서 열리지만, 드롭다운 메뉴를 사용하면 Docker, CloudFormation, Terraform, Ansible 중에서 선택할 수 있습니다).
어떻게 됐어? 아직 할 일이 남아 있다면 계속 읽어봐:
보안 기능은 다양한 이유로 비활성화될 수 있습니다. 일부 애플리케이션과 프레임워크는 기본적으로 비활성화되어 있을 수 있으며, 작동하려면 먼저 활성화해야 합니다. 또한 관리자가 특정 작업을 더 쉽게 수행하기 위해 지속적인 문제나 차단 없이(예: AWS S3 버킷 공개) 특정 보안 기능을 비활성화했을 수도 있습니다. 작업이 완료된 후, 비활성화된 기능을 다시 활성화하는 것을 잊을 수도 있습니다. 또한 향후 작업을 용이하게 하기 위해 해당 기능을 계속 비활성화 상태로 유지하는 것을 선호할 수도 있습니다.
비활성화된 보안 기능이 왜 그렇게 위험한가
하나 이상의 보안 기능을 비활성화하는 것은 여러 가지 이유로 좋지 않습니다. 첫째, 해당 보안 기능은 알려진 악용, 위협 또는 취약점으로부터 인프라 자원을 보호하기 위해 포함되었습니다. 비활성화된 상태에서는 자원을 보호할 수 없습니다.
공격자들은 항상 먼저 쉽게 악용할 수 있는 취약점을 찾으려 할 것이며, 심지어 가장 흔한 약점을 분석하기 위해 스크립트를 사용할 수도 있습니다. 이는 마치 한 거리의 모든 차량을 확인하여 창문을 깨는 것보다 훨씬 쉬운 열린 문이 있는지 살펴보는 도둑과 같습니다. 해커들은 일반적인 보안 방어 체계가 작동하지 않는다는 사실을 발견하면 놀랄 것입니다. 하지만 그런 상황이 발생하면, 그들은 이를 악용하는 데 오래 걸리지 않을 것입니다.
둘째, 우수한 보안 시스템을 구축한 후 이를 비활성화하면 허위의 안전감을 조성합니다. 관리자들은 누군가가 해당 방어 체계를 비활성화했다는 사실을 모른다면 가장 흔한 위협으로부터 보호받고 있다고 생각할 수 있습니다.
공격자가 비활성화된 보안 기능을 악용할 수 있는 사례로, AWS S3의 공개 액세스 차단 보안 기능을 살펴보겠습니다. Amazon S3의 공개 액세스 차단 기능을 사용하면 계정 관리자 및 저장소 소유자가 Amazon S3 리소스에 대한 공개 액세스를 제한하기 위한 중앙 집중식 제어를 쉽게 구성할 수 있습니다. 그러나 일부 관리자는 S3 버킷 접근에 문제가 생기면 작업을 최대한 빨리 완료하기 위해 버킷을 공개하기로 결정합니다. 이 보안 기능을 활성화하는 것을 잊어버리면 공격자는 해당 S3 버킷에 저장된 정보에 대한 완전한 접근 권한을 얻게 되며, 이는 정보 유출을 초래할 뿐만 아니라 데이터 전송 비용으로 인한 추가 비용 발생으로 이어집니다.
실제 코드 몇 가지를 비교해 보겠습니다. 다음 CloudFormation 스니펫을 참조하세요:
취약:
기업용 큐브:
유형: AWS: :S3: :Bucket
속성:
공개 액세스 블록 설정:
blockPublicACLS: false
BlockPublicPolicy: false
ignorePublicacls: false
restrictPublicBuckets: false
버전 관리 설정:
상태: 활성화됨
버킷 암호화:
서버 측 암호화 설정:
- 기본 서버 측 암호화:
SSE 알고리즘: «AES256»
세구로:
기업용 큐브:
유형: AWS: :S3: :Bucket
속성:
공개 액세스 블록 설정:
BlockPublicACLS: true
BlockPublicPolicy: true
ignorePublicacls: true
RestrictPublicBuckets: true
버전 관리 설정:
상태: 활성화됨
버킷 암호화:
서버 측 암호화 설정:
- 기본 서버 측 암호화:
SSE 알고리즘: "AES256"
비활성화된 보안 기능 방지
보안 기능의 비활성화가 조직에 부정적인 영향을 미치지 않도록 하는 것은 정책과 실행 모두에 관한 문제입니다. 보안 기능은 매우 특정된 상황에서만 비활성화되어야 한다는 명확한 정책이 수립되어야 합니다. 문제 해결이나 애플리케이션 업데이트를 위해 기능을 일시적으로 비활성화해야 하는 상황은 반드시 기록되어야 합니다. 필요한 작업이 완료된 후에는 해당 기능이 완전히 재활성화되었는지 반드시 확인해야 합니다.
보안 기능을 영구적으로 비활성화하여 운영을 간소화해야 하는 경우, 해당 데이터에 대한 다른 보호 장치를 마련하여 기본 보호 기능이 없는 상태에서도 해커가 접근할 수 없도록 보장해야 합니다. 필수 보호 기능을 비활성화한 경우, 공격자가 열린 문을 발견하고 이를 악용하는 것은 시간 문제일 뿐입니다.
더 많은 정보를 얻고, 스스로에게 도전하세요:
한번 살펴보세요 Secure Code Warrior 블로그 페이지를 방문하여 이 취약점에 대한 자세한 정보와 조직 및 고객을 다른 보안 결함 및 취약점의 피해로부터 보호하는 방법을 알아보세요.
게시물을 읽으셨으니 이제 이 취약점을 찾아 수정할 준비가 되셨나요? 지금 바로 시작하세요! Secure Code Warrior 플랫폼에서iMac용 게임화된 보안 챌린지를 시도해 보세요. 사이버 보안 기술을 완벽하게 연마하고 최신 상태로 유지할 Secure Code Warrior .
이것은 코드로서의 인프라(Infrastructure as Code)의 주요 취약점 8가지를 다루는 주간 시리즈입니다. 다음 주에 더 많은 정보를 얻으러 다시 찾아오세요!
목차
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Secure Code Warrior 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.
데모 예약하기다운로드
%20(1).avif)
.avif)
