코드 시리즈로 보안 인프라를 정복하는 코더 - 신뢰할 수 없는 출처의 구성 요소 사용

Infrastructure as Code 시리즈가 거의 끝나갈 무렵이지만 IaC 보안 여정에서 여러분과 같은 개발자를 도울 수 있어서 정말 좋았습니다.

챌린지를 플레이해 보셨나요?지금까지 어떤 점수가 나왔나요?시작하기 전에 신뢰할 수 없는 출처의 구성 요소를 사용할 때 발생할 수 있는 함정에 대해 이미 얼마나 알고 있는지 살펴보겠습니다.

아직 해야 할 일이 있나요?계속 읽어보세요:

오늘날 우리가 집중적으로 살펴볼 취약점 유발 행위는 신뢰할 수 없는 출처의 코드를 사용하는 것인데, 이는 겉보기에 무해해 보이지만 큰 문제를 일으키고 있습니다.오픈 소스 코드와 리소스를 사용하면 많은 이점이 있습니다.일반적으로 전문가들이 자신의 아이디어, 작업, 완성된 코드를 GitHub와 같은 저장소에 제공하여 프로그램이나 앱이 제대로 작동하도록 하는 데 어려움을 겪고 있는 다른 사람들이 사용할 수 있도록 합니다.완성된 코드를 사용하여 프로그램 기능을 관리하면 개발자가 새 애플리케이션을 만들어야 할 때마다 처음부터 다시 만들지 않아도 됩니다.

그러나 신뢰할 수 없거나 알려지지 않았거나 잠재적으로 위험한 출처의 코드 스니펫을 사용하는 것은 많은 위험을 수반합니다.사실 신뢰할 수 없는 출처의 코드를 사용하는 것은 크고 작은 보안 취약점이 보안 애플리케이션에 침투하는 가장 일반적인 방법 중 하나입니다.이러한 취약점은 제작자가 실수로 유발한 경우도 있습니다.잠재적 공격자가 악성 코드를 작성한 사례도 있습니다.그런 다음 해당 코드를 공유하여 피해자가 자신의 애플리케이션에 코드를 삽입하도록 유혹할 수 있도록 합니다.

신뢰할 수 없는 출처의 코드를 사용하는 것이 왜 위험한가요?

개발자가 급해서 개발 중인 애플리케이션을 구성해야 한다고 가정해 보겠습니다.이는 까다로운 프로세스일 수 있습니다.따라서 가능한 모든 구성을 알아내느라 많은 시간을 소비하는 대신 Google 검색을 통해 겉보기에 완벽해 보이는 구성 파일을 이미 완성한 사람을 찾습니다.개발자가 코드를 작성한 사람에 대해 아는 것이 없더라도 새 애플리케이션에 코드를 추가하는 것은 비교적 쉽습니다.Docker 환경에서는 다음 두 줄을 사용하여 수행할 수 있습니다.

cd /etc/apache2/사이트 실행 가능/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

이제 Docker 이미지는 타사 구성 파일을 동적으로 가져옵니다.그리고 파일을 테스트한 결과 당시에는 문제가 없는 것으로 확인되더라도 이제 포인터가 새 애플리케이션의 코드에 포함되어 있다는 사실은 영구적인 종속성이 존재한다는 것을 의미합니다.며칠, 몇 주 또는 몇 달이 지나면 원래 작성자나 코드 저장소를 손상시킨 공격자에 의해 파일이 변경될 수 있습니다.갑자기 공유된 구성 파일이 응용 프로그램이 의도한 것과 매우 다르게 작동하도록 지시하여 권한 없는 사용자에게 액세스 권한을 부여하거나 직접 데이터를 훔쳐 유출할 수도 있습니다.

공유 리소스를 사용하는 더 나은 방법

조직에서 외부 소스의 코드 사용을 허용하는 경우 안전하게 수행되도록 하는 프로세스를 마련해야 합니다.외부 코드의 활용 가능성을 평가할 때는 반드시 보안 링크를 사용하여 공식 소스로부터 구성 요소를 구해야 합니다.그런 경우에도 외부 소스에 연결하여 코드를 가져와서는 안 됩니다. 그러면 프로세스를 제어할 수 없게 되기 때문입니다.대신 승인된 코드를 안전한 라이브러리로 가져와 보호된 위치에서만 사용해야 합니다.따라서 Docker 환경에서는 코드가 다음과 같이 보일 것입니다.

복사 src/config/default-ssl.conf /etc/apache2/sites-available/

원격 타사 구성 파일에 의존하는 대신 해당 파일의 로컬 복사본을 사용합니다.이렇게 하면 예상치 못한 변경이나 악의적인 변경을 방지할 수 있습니다.

보안 코드 라이브러리를 사용하는 것 외에도 소프트웨어 라이프사이클 전반에 걸쳐 구성 요소를 지속적으로 모니터링할 수 있는 패치 관리 프로세스를 마련해야 합니다.또한 NVD 또는 CVE와 같은 도구를 사용하여 모든 클라이언트 및 서버 측 구성 요소에 보안 경고가 있는지 확인해야 합니다.마지막으로, 외부 코드와 함께 사용할 수 있는 사용하지 않거나 불필요한 종속성 및 기능을 제거하세요.

이러한 단계를 따르면 개발자는 실수로 애플리케이션 및 코드에 취약점을 유발하지 않고 외부 리소스를 더 안전하게 사용할 수 있습니다.

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