코더는 보안 인프라를 코드 시리즈로 정복 - 신뢰할 수 없는 소스의 구성 요소를 사용
우리는 코드 시리즈로 인프라의 끝에 가까워지고 있지만 IaC 보안 여정에 대해 여러분과 같은 개발자를 도울 수 있었습니다.
당신은 도전을 연주 한 적이 있습니까? 지금까지 점수는 무엇입니까? 시작하기 전에 신뢰할 수 없는 소스의 구성 요소를 사용하는 함정에 대해 이미 얼마나 알고 있는지 살펴보겠습니다.
아직도 해야 할 일이 몇 가지 있습니까? 읽기:
오늘날 우리가 집중할 취약점 유도 동작은 신뢰할 수 없는 출처의 코드를 사용하는 것이며, 이는 큰 문제를 일으키는 것처럼 보이는 양성 관행입니다. 오픈 소스 코드 및 리소스를 사용하는 데는 많은 장점이 있습니다. 일반적으로 전문가가 프로그램이나 앱을 제대로 작동시키기 위해 고군분투하는 다른 사람들이 GitHub와 같은 리포지토리에 아이디어를 기여하고 작업하며 심지어 완료된 코드를 사용할 수 있습니다. 완성된 코드를 사용하여 프로그램 기능을 제어하면 개발자가 새 응용 프로그램을 만드는 데 필요할 때마다 휠을 재창조할 필요가 없습니다.
그러나 신뢰할 수 없거나 검증되지 않거나 잠재적으로 위험한 소스의 코드 조각을 사용하면 많은 위험이 따릅니다. 실제로 신뢰할 수 없는 소스의 코드를 사용하는 것은 주요 및 사소한 보안 취약점이 보안 응용 프로그램으로 크리프하는 가장 일반적인 방법 중 하나입니다. 경우에 따라 이러한 취약점은 제작자에 의해 실수로 유도됩니다. 잠재적 공격자에 의해 악성 코드가 작성된 경우도 있습니다. 그런 다음 코드는 응용 프로그램에 삭제할 피해자를 유혹할 수 있다는 희망과 공유됩니다.
신뢰할 수 없는 소스의 코드를 사용하는 것이 위험한 이유는 무엇입니까?
개발자가 급하게 개발 중인 응용 프로그램을 구성해야 한다고 가정해 보겠습니다. 그것은 까다로운 과정이 될 수 있습니다. 따라서 가능한 모든 구성을 작업하는 데 많은 시간을 할애하는 대신 Google 검색을 수행하며 이미 완벽한 구성 파일을 완료한 사람을 찾습니다. 개발자가 코드를 작성한 사람에 대해 아무 것도 알지 못하지만 새 응용 프로그램에 추가하는 것은 비교적 쉽습니다. 두 줄을 사용하여 Docker 환경에서 수행할 수 있습니다.
실행 CD /etc /apache2/사이트 사용 가능/ & \
wget -O 기본-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/원시/\
fbdfbe230fa256a6fb78e5e0000aebed60d6a5ef/default-ssl.conf
이제 Docker 이미지가 타사 구성 파일에서 동적으로 가져옵니다. 그리고 파일이 테스트되고 당시 괜찮은 것으로 판명되더라도 포인터가 새 응용 프로그램의 코드에 포함된다는 사실은 영구적인 종속성이 있음을 의미합니다. 며칠, 몇 주 또는 몇 달 후, 파일은 원래 작성자 또는 코드 리포지토리를 손상한 공격자에 의해 변경될 수 있습니다. 갑자기 공유 구성 파일은 응용 프로그램이 의도한 것과 매우 다르게 수행하도록 지시할 수 있으며, 권한이 없는 사용자에게 액세스 권한을 부여하거나 데이터를 직접 도용하고 유출할 수도 있습니다.
공유 리소스를 사용하는 더 나은 방법
조직에서 외부 소스에서 코드를 사용할 수 있도록 허용하는 경우 안전하게 수행되도록 프로세스를 배치해야 합니다. 잠재적인 사용을 위해 외부 코드를 평가할 때는 보안 링크를 사용하여 공식 소스에서 구성 요소를 획득해야 합니다. 그럼에도 불구하고 컨트롤에서 프로세스를 제거하기 때문에 외부 소스에 연결하여 해당 코드를 끌어서는 안 됩니다. 대신 승인된 코드를 보안 라이브러리로 가져와야 하며 보호된 위치에서만 사용해야 합니다. 따라서 Docker 환경에서코드는 다음과 같습니다.
카피 src/config/default-ssl.conf/etc/아파치2/사이트 이용 가능/
원격 타사 구성 파일에 의존하는 대신 해당 파일의 로컬 복사본에 의존합니다. 이렇게 하면 예기치 않거나 악의적인 변경이 발생하지 않습니다.
보안 코드 라이브러리를 사용하는 것 외에도 소프트웨어 수명 주기 전반에 걸쳐 구성 요소를 지속적으로 모니터링하기 위해 패치 관리 프로세스를 배치해야 합니다. 모든 클라이언트 및 서버 측 구성 요소도 NVD 또는 CVE와 같은 도구를 사용하여 보안 경고를 확인해야 합니다. 마지막으로 외부 코드로 라이딩을 위해 사용할 수 있는 사용되지 않거나 불필요한 종속성 및 기능을 제거합니다.
개발자는 이러한 단계를 수행함으로써 응용 프로그램 및 코드에 실수로 취약점을 유도하지 않고도 외부 리소스를 보다 안전하게 사용할 수 있습니다.
체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. IaC 챌린지데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.
마티아스 마두, Ph.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
블로그에서 최신 보안 코딩 인사이트에 대해 자세히 알아보세요.
Atlassian의 광범위한 리소스 라이브러리는 안전한 코딩 숙련도를 확보하기 위한 인적 접근 방식을 강화하는 것을 목표로 합니다.
개발자 중심 보안에 대한 최신 연구 보기
광범위한 리소스 라이브러리에는 개발자 중심의 보안 코딩을 시작하는 데 도움이 되는 백서부터 웨비나까지 유용한 리소스가 가득합니다. 지금 살펴보세요.
코더는 보안 인프라를 코드 시리즈로 정복 - 신뢰할 수 없는 소스의 구성 요소를 사용
우리는 코드 시리즈로 인프라의 끝에 가까워지고 있지만 IaC 보안 여정에 대해 여러분과 같은 개발자를 도울 수 있었습니다.
당신은 도전을 연주 한 적이 있습니까? 지금까지 점수는 무엇입니까? 시작하기 전에 신뢰할 수 없는 소스의 구성 요소를 사용하는 함정에 대해 이미 얼마나 알고 있는지 살펴보겠습니다.
아직도 해야 할 일이 몇 가지 있습니까? 읽기:
오늘날 우리가 집중할 취약점 유도 동작은 신뢰할 수 없는 출처의 코드를 사용하는 것이며, 이는 큰 문제를 일으키는 것처럼 보이는 양성 관행입니다. 오픈 소스 코드 및 리소스를 사용하는 데는 많은 장점이 있습니다. 일반적으로 전문가가 프로그램이나 앱을 제대로 작동시키기 위해 고군분투하는 다른 사람들이 GitHub와 같은 리포지토리에 아이디어를 기여하고 작업하며 심지어 완료된 코드를 사용할 수 있습니다. 완성된 코드를 사용하여 프로그램 기능을 제어하면 개발자가 새 응용 프로그램을 만드는 데 필요할 때마다 휠을 재창조할 필요가 없습니다.
그러나 신뢰할 수 없거나 검증되지 않거나 잠재적으로 위험한 소스의 코드 조각을 사용하면 많은 위험이 따릅니다. 실제로 신뢰할 수 없는 소스의 코드를 사용하는 것은 주요 및 사소한 보안 취약점이 보안 응용 프로그램으로 크리프하는 가장 일반적인 방법 중 하나입니다. 경우에 따라 이러한 취약점은 제작자에 의해 실수로 유도됩니다. 잠재적 공격자에 의해 악성 코드가 작성된 경우도 있습니다. 그런 다음 코드는 응용 프로그램에 삭제할 피해자를 유혹할 수 있다는 희망과 공유됩니다.
신뢰할 수 없는 소스의 코드를 사용하는 것이 위험한 이유는 무엇입니까?
개발자가 급하게 개발 중인 응용 프로그램을 구성해야 한다고 가정해 보겠습니다. 그것은 까다로운 과정이 될 수 있습니다. 따라서 가능한 모든 구성을 작업하는 데 많은 시간을 할애하는 대신 Google 검색을 수행하며 이미 완벽한 구성 파일을 완료한 사람을 찾습니다. 개발자가 코드를 작성한 사람에 대해 아무 것도 알지 못하지만 새 응용 프로그램에 추가하는 것은 비교적 쉽습니다. 두 줄을 사용하여 Docker 환경에서 수행할 수 있습니다.
실행 CD /etc /apache2/사이트 사용 가능/ & \
wget -O 기본-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/원시/\
fbdfbe230fa256a6fb78e5e0000aebed60d6a5ef/default-ssl.conf
이제 Docker 이미지가 타사 구성 파일에서 동적으로 가져옵니다. 그리고 파일이 테스트되고 당시 괜찮은 것으로 판명되더라도 포인터가 새 응용 프로그램의 코드에 포함된다는 사실은 영구적인 종속성이 있음을 의미합니다. 며칠, 몇 주 또는 몇 달 후, 파일은 원래 작성자 또는 코드 리포지토리를 손상한 공격자에 의해 변경될 수 있습니다. 갑자기 공유 구성 파일은 응용 프로그램이 의도한 것과 매우 다르게 수행하도록 지시할 수 있으며, 권한이 없는 사용자에게 액세스 권한을 부여하거나 데이터를 직접 도용하고 유출할 수도 있습니다.
공유 리소스를 사용하는 더 나은 방법
조직에서 외부 소스에서 코드를 사용할 수 있도록 허용하는 경우 안전하게 수행되도록 프로세스를 배치해야 합니다. 잠재적인 사용을 위해 외부 코드를 평가할 때는 보안 링크를 사용하여 공식 소스에서 구성 요소를 획득해야 합니다. 그럼에도 불구하고 컨트롤에서 프로세스를 제거하기 때문에 외부 소스에 연결하여 해당 코드를 끌어서는 안 됩니다. 대신 승인된 코드를 보안 라이브러리로 가져와야 하며 보호된 위치에서만 사용해야 합니다. 따라서 Docker 환경에서코드는 다음과 같습니다.
카피 src/config/default-ssl.conf/etc/아파치2/사이트 이용 가능/
원격 타사 구성 파일에 의존하는 대신 해당 파일의 로컬 복사본에 의존합니다. 이렇게 하면 예기치 않거나 악의적인 변경이 발생하지 않습니다.
보안 코드 라이브러리를 사용하는 것 외에도 소프트웨어 수명 주기 전반에 걸쳐 구성 요소를 지속적으로 모니터링하기 위해 패치 관리 프로세스를 배치해야 합니다. 모든 클라이언트 및 서버 측 구성 요소도 NVD 또는 CVE와 같은 도구를 사용하여 보안 경고를 확인해야 합니다. 마지막으로 외부 코드로 라이딩을 위해 사용할 수 있는 사용되지 않거나 불필요한 종속성 및 기능을 제거합니다.
개발자는 이러한 단계를 수행함으로써 응용 프로그램 및 코드에 실수로 취약점을 유도하지 않고도 외부 리소스를 보다 안전하게 사용할 수 있습니다.
체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. IaC 챌린지데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.
