.jpg)
.jpg)
강력한 코드 서명 절차를 보유하고 있다는 건 소프트웨어 개발을 해야 하는 입장에서 든든한 일이다. 공급망에 대한 염려거리도 하나 줄어든다. 코드 서명 절차가 안전하게 유지되려면 꼭 해야 할 일들이 있어 정리한다.
[보안뉴스= 무랄리 팔라니사미 CSO, AppViewX] 원격 접근 솔루션인 애니데스크(AnyDesk)에서 최근 침해 사고가 발생했다. 알고 봤더니 코드 서명 절차에 문제가 있었고, 거기서부터 공격이 시작된 것이었다. 이 사건에 관심을 기울였던 모든 사람들은 자기 회사의 코드 서명 절차를 되돌아보지 않을 수 없었다.
‘코드 서명’이라는 것은 소프트웨어나 펌웨어, 애플리케이션들에 말 그대로 서명을 하는 것으로, 이 서명 덕분에 사용자들은 그 소프트웨어나 펌웨어, 애플리케이션을 구성하고 있는 코드가 신뢰할 수 있는 것이라는 걸 알게 된다. 하지만 그 서명이 가짜로 바뀌거나, 서명 절차에 누군가 개입해 남용할 수 있다면 ‘코드 서명’이라는 것은 더 이상 신뢰할 수 없는 것이 된다. 실제 이런 일들은 심심치 않게 일어나는 편이고, 그러면서 악성 코드나 소프트웨어가 신뢰 받는 코드인 것처럼 퍼져간다.
코드를 서명하는 데 사용되는 비밀 키는 상당히 주의해서 보호해야 한다. 하지만 주의 깊게 보호하면서 소프트웨어를 개발하려면 여러 모로 귀찮은 일이 발생한다. 그렇기 때문에 개발자들은 비밀 키들을 각자의 개발 환경과 기계와 계정들에 저장해둔다. 편리하게, 원할 때마다 간편하게 꺼내 쓰기 위함이다. 그렇기 때문에 비밀 키는 생각보다 자주 도난 당하고 유출된다. 공격자들도 이를 잘 알고 있다.
2020년 솔라윈즈(SolarWinds) 사태가 발생한 이후 CA브라우저포럼(Certificate Authority/Browser Forum)은 코드 서명 인증서들을 지키기 위한 새로운 ‘기본 실천 수칙’을 발표했다. 그러면서 하드웨어 보안 모듈(HSM)이나 암호화 키를 안전히 보관하는 장비들을 필수로 사용해야 한다는 수칙이 생겼다.
HSM은 가장 높은 수위의 보호 장치로서 역할을 하기도 하지만 비용을 상승시킨다는 단점도 가지고 있다. 게다가 유지 보수 난이도도 높은 편이고, 시스템과 네트워크를 꽤나 복잡하게 만들기도 한다. 따라서 개발자들의 선택을 받지 못하며, 회사가 정책으로 정한다 해도 HSM은 간과되거나 유기되기 일쑤다. 지나치게 보안 쪽으로만 치우쳐져 있는 이상이라는 것이다. 현장에서의 생산성은 크게 고려되지 않는 방법이라고 할 수 있다. 그러므로 ‘유지되는 보안’과는 거리가 먼 것이 됐다.
클라우드로의 이전이 크게 유행하기 시작하면서 보안의 중요성은 더욱 대두됐다. 또한 안전한 코드 서명과 관련하여 새로운 해결책을 제시하기도 했다. 개발자들이 원하는 편리함과 속도를 갖춘 코드 서명 기술 및 절차가 클라우드를 통해 만들어질 수 있었던 것이다. 그러면서도 중앙에서 비밀 키를 관리하는 것도 가능해졌다. 그러면서 안전한 코드 서명을 ‘유지’할 수 있게 됐다.
통합된 코드 서명 절차
그렇게 코드 서명이라는 절차도 점점 현대화의 길을 걸어가게 됐다. 그렇지만 이제 막 시작인 단계이지, 많은 기업들은 아직 예전처럼 그 때 그 때 필요한 대로 코드 서명을 한다. 코드 서명을 보호해야 한다거나 강력히 한다거나 현대화 한다는 개념을 가지고 변화를 시도하는 곳은 많지 않다. 여전히 서명을 위한 비밀 키는 로컬 시스템 여기 저기에 저장되어 있고, 개발자들은 별 생각없이 이것을 가져다가 필요한 대로 서명을 진행했다.
코드 서명 프로세스는 키 보안, 코드 서명 도구, 개발 워크플로우로 구성되어 있다. 이 세 가지가 유연하고 부드럽게, 장애 없이 순환되어야 이상적이다. 키가 안전하게 보호되면서 코드 서명 도구들에 활용되고, 그러면서도 동시에 개발에도 잘 활용되어야 한다는 것이다. 그래야 코드 서명의 안전성이 유지될 수 있다. 이를 위해 지켜야 할 몇 가지 실천 사항이 있는데, 다음과 같다.
1) 키 보호 : 코드 서명에 사용되는 키들은 안전한 위치에 저장해야 한다. CA브라우저포럼의 암호화 필수 사항과 호환이 되는 HSM(FIPS 140-2 레벨이나 공통평가기준 EAL 4 이상)이 좋은 예가 될 수 있다. 또한 HSM들은 내부에 저장된 비밀 키들이 엑스포트 되지 않도록 해야 하고, 허가되지 않은 조작을 허용하지 않아야 한다.
2) 접근 제어 : 비밀 키에 접근하려는 시도를 철저하게 가려내고 제어할 수 있어야 한다. 특히 지위의 높고 낮음이 아니라 역할에 따라 키 접근을 허용해주거나 막는 것이 중요하다. 이를 위해서는 먼저 승인 작업의 워크플로우를 규정할 필요가 있다. 역할에 따라 허용하거나 차단하는 건, 승인 작업을 여러 번 한다는 뜻이 된다. 또한 승인 과정에 대한 기록을 남기는 체제도 확립해야 한다. 그래야 서명 작업과 관련된 문제가 발생했을 때 거슬러 올라가 원인을 파악하기가 쉬워진다.
3) 비밀 키 순환 : 서명 키 하나가 침해당하면, 그 키로 서명한 모든 코드들이 위험해진다. 그러므로 사건이 특별하게 터지지 않더라도 서명 키는 주기적으로 교체해주는 것이 좋다. 또한 여러 개발 팀들이 하나의 개발 플랫폼이나 환경을 공유한다면, 비밀 키를 따로 보관하여 활용하도록 하는 게 훨씬 안전하고 효율적이다.
4) 타임스탬프 : 코드를 서명하는 데 사용되는 인증서들은 유효기간을 가지고 있다. 적게는 1년에서, 많게는 3년까지다. 그리고 요즘은 인증서 유효기간들이 점점 줄어드는 추세다. 안전을 위해서다. 그렇기에 인증서가 제대로 된 것인지 아닌지 타임스탬프를 찍는 것이 중요하다. 그래야 유효한 것인지, 시간이 얼마나 지난 것인지, 어디서부터 유효기간이 틀어졌는지 확인 및 추적이 가능하다.
5) 코드 무결성 확인 : 전체 코드 점검을 한 후에 서명을 하는 순서가 반드시 지켜지도록 하는 게 중요하다. 빌드 서버와 소스코드 리포지터리를 비교해 확인한 후 최종 빌드를 공개하는 것을 추천한다. 또한 모든 개발자 서명들도 하나하나 확인하는 것이 좋다.
6) 관리의 중앙화 : 오늘날에는 모든 사업들이 여기 저기 흩어져서 진행된다. 국제적 기업이 아니더라도, 여러 임직원이 여러 지역에서 자신의 할 일을 하는 경우가 많다. 그렇기 때문에 각자가 필요한 때에 서명을 하곤 하는데, 그러면서 서명 관리자 되지 않는다. 그렇기 때문에 코드 서명 과정을 중앙에서 통제하도록 하는 게 가시성 확보나 빌드 신뢰도 향상 등의 측면에서 유리하다.
7) 정책의 강력한 시행 : 코드 서명 절차를 수립했다면, 그것을 조직 전체의 규정으로 만들어 시행해야 한다. 정책화해야 한다는 것이다. 이걸 가이드라인 등 강제력이 없는 것으로 퍼트리면 아무도 지키지 않는다. 승인, 키 만료, CA 유형, 키 용량, 서명 알고리즘 등을 세부적으로 지정해 시행시켜야 한다. 또한 정책 시행이 자동으로 확인되도록 자동화 기술을 도입하는 것도 중요하다.
8) 코드 서명의 간소화 : CI/CD 도구들을 활용해 코드 서명을 자동화 하는 것을 꾀하는 것으로 코드 서명 현대화를 마무리 짓는 것이 좋다. 그래야 개발자들이 코드 서명의 안전이나 온전함에 크게 신경을 쓰지 않고도 안전하게 개발 행위를 할 수 있기 때문이다. 그러면서도 안전할 수 있다. 즉 개발자들이 보안에 크게 신경 쓰지 않아야 보안이 유지될 수 있다.
글 : 무랄리 팔라니사미(Murali Palanisamy), CSO, AppViewX
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스= 무랄리 팔라니사미 CSO, AppViewX] 원격 접근 솔루션인 애니데스크(AnyDesk)에서 최근 침해 사고가 발생했다. 알고 봤더니 코드 서명 절차에 문제가 있었고, 거기서부터 공격이 시작된 것이었다. 이 사건에 관심을 기울였던 모든 사람들은 자기 회사의 코드 서명 절차를 되돌아보지 않을 수 없었다.
[이미지 = gettyimagesbank]
‘코드 서명’이라는 것은 소프트웨어나 펌웨어, 애플리케이션들에 말 그대로 서명을 하는 것으로, 이 서명 덕분에 사용자들은 그 소프트웨어나 펌웨어, 애플리케이션을 구성하고 있는 코드가 신뢰할 수 있는 것이라는 걸 알게 된다. 하지만 그 서명이 가짜로 바뀌거나, 서명 절차에 누군가 개입해 남용할 수 있다면 ‘코드 서명’이라는 것은 더 이상 신뢰할 수 없는 것이 된다. 실제 이런 일들은 심심치 않게 일어나는 편이고, 그러면서 악성 코드나 소프트웨어가 신뢰 받는 코드인 것처럼 퍼져간다.
코드를 서명하는 데 사용되는 비밀 키는 상당히 주의해서 보호해야 한다. 하지만 주의 깊게 보호하면서 소프트웨어를 개발하려면 여러 모로 귀찮은 일이 발생한다. 그렇기 때문에 개발자들은 비밀 키들을 각자의 개발 환경과 기계와 계정들에 저장해둔다. 편리하게, 원할 때마다 간편하게 꺼내 쓰기 위함이다. 그렇기 때문에 비밀 키는 생각보다 자주 도난 당하고 유출된다. 공격자들도 이를 잘 알고 있다.
2020년 솔라윈즈(SolarWinds) 사태가 발생한 이후 CA브라우저포럼(Certificate Authority/Browser Forum)은 코드 서명 인증서들을 지키기 위한 새로운 ‘기본 실천 수칙’을 발표했다. 그러면서 하드웨어 보안 모듈(HSM)이나 암호화 키를 안전히 보관하는 장비들을 필수로 사용해야 한다는 수칙이 생겼다.
HSM은 가장 높은 수위의 보호 장치로서 역할을 하기도 하지만 비용을 상승시킨다는 단점도 가지고 있다. 게다가 유지 보수 난이도도 높은 편이고, 시스템과 네트워크를 꽤나 복잡하게 만들기도 한다. 따라서 개발자들의 선택을 받지 못하며, 회사가 정책으로 정한다 해도 HSM은 간과되거나 유기되기 일쑤다. 지나치게 보안 쪽으로만 치우쳐져 있는 이상이라는 것이다. 현장에서의 생산성은 크게 고려되지 않는 방법이라고 할 수 있다. 그러므로 ‘유지되는 보안’과는 거리가 먼 것이 됐다.
클라우드로의 이전이 크게 유행하기 시작하면서 보안의 중요성은 더욱 대두됐다. 또한 안전한 코드 서명과 관련하여 새로운 해결책을 제시하기도 했다. 개발자들이 원하는 편리함과 속도를 갖춘 코드 서명 기술 및 절차가 클라우드를 통해 만들어질 수 있었던 것이다. 그러면서도 중앙에서 비밀 키를 관리하는 것도 가능해졌다. 그러면서 안전한 코드 서명을 ‘유지’할 수 있게 됐다.
통합된 코드 서명 절차
그렇게 코드 서명이라는 절차도 점점 현대화의 길을 걸어가게 됐다. 그렇지만 이제 막 시작인 단계이지, 많은 기업들은 아직 예전처럼 그 때 그 때 필요한 대로 코드 서명을 한다. 코드 서명을 보호해야 한다거나 강력히 한다거나 현대화 한다는 개념을 가지고 변화를 시도하는 곳은 많지 않다. 여전히 서명을 위한 비밀 키는 로컬 시스템 여기 저기에 저장되어 있고, 개발자들은 별 생각없이 이것을 가져다가 필요한 대로 서명을 진행했다.
코드 서명 프로세스는 키 보안, 코드 서명 도구, 개발 워크플로우로 구성되어 있다. 이 세 가지가 유연하고 부드럽게, 장애 없이 순환되어야 이상적이다. 키가 안전하게 보호되면서 코드 서명 도구들에 활용되고, 그러면서도 동시에 개발에도 잘 활용되어야 한다는 것이다. 그래야 코드 서명의 안전성이 유지될 수 있다. 이를 위해 지켜야 할 몇 가지 실천 사항이 있는데, 다음과 같다.
1) 키 보호 : 코드 서명에 사용되는 키들은 안전한 위치에 저장해야 한다. CA브라우저포럼의 암호화 필수 사항과 호환이 되는 HSM(FIPS 140-2 레벨이나 공통평가기준 EAL 4 이상)이 좋은 예가 될 수 있다. 또한 HSM들은 내부에 저장된 비밀 키들이 엑스포트 되지 않도록 해야 하고, 허가되지 않은 조작을 허용하지 않아야 한다.
2) 접근 제어 : 비밀 키에 접근하려는 시도를 철저하게 가려내고 제어할 수 있어야 한다. 특히 지위의 높고 낮음이 아니라 역할에 따라 키 접근을 허용해주거나 막는 것이 중요하다. 이를 위해서는 먼저 승인 작업의 워크플로우를 규정할 필요가 있다. 역할에 따라 허용하거나 차단하는 건, 승인 작업을 여러 번 한다는 뜻이 된다. 또한 승인 과정에 대한 기록을 남기는 체제도 확립해야 한다. 그래야 서명 작업과 관련된 문제가 발생했을 때 거슬러 올라가 원인을 파악하기가 쉬워진다.
3) 비밀 키 순환 : 서명 키 하나가 침해당하면, 그 키로 서명한 모든 코드들이 위험해진다. 그러므로 사건이 특별하게 터지지 않더라도 서명 키는 주기적으로 교체해주는 것이 좋다. 또한 여러 개발 팀들이 하나의 개발 플랫폼이나 환경을 공유한다면, 비밀 키를 따로 보관하여 활용하도록 하는 게 훨씬 안전하고 효율적이다.
4) 타임스탬프 : 코드를 서명하는 데 사용되는 인증서들은 유효기간을 가지고 있다. 적게는 1년에서, 많게는 3년까지다. 그리고 요즘은 인증서 유효기간들이 점점 줄어드는 추세다. 안전을 위해서다. 그렇기에 인증서가 제대로 된 것인지 아닌지 타임스탬프를 찍는 것이 중요하다. 그래야 유효한 것인지, 시간이 얼마나 지난 것인지, 어디서부터 유효기간이 틀어졌는지 확인 및 추적이 가능하다.
5) 코드 무결성 확인 : 전체 코드 점검을 한 후에 서명을 하는 순서가 반드시 지켜지도록 하는 게 중요하다. 빌드 서버와 소스코드 리포지터리를 비교해 확인한 후 최종 빌드를 공개하는 것을 추천한다. 또한 모든 개발자 서명들도 하나하나 확인하는 것이 좋다.
6) 관리의 중앙화 : 오늘날에는 모든 사업들이 여기 저기 흩어져서 진행된다. 국제적 기업이 아니더라도, 여러 임직원이 여러 지역에서 자신의 할 일을 하는 경우가 많다. 그렇기 때문에 각자가 필요한 때에 서명을 하곤 하는데, 그러면서 서명 관리자 되지 않는다. 그렇기 때문에 코드 서명 과정을 중앙에서 통제하도록 하는 게 가시성 확보나 빌드 신뢰도 향상 등의 측면에서 유리하다.
7) 정책의 강력한 시행 : 코드 서명 절차를 수립했다면, 그것을 조직 전체의 규정으로 만들어 시행해야 한다. 정책화해야 한다는 것이다. 이걸 가이드라인 등 강제력이 없는 것으로 퍼트리면 아무도 지키지 않는다. 승인, 키 만료, CA 유형, 키 용량, 서명 알고리즘 등을 세부적으로 지정해 시행시켜야 한다. 또한 정책 시행이 자동으로 확인되도록 자동화 기술을 도입하는 것도 중요하다.
8) 코드 서명의 간소화 : CI/CD 도구들을 활용해 코드 서명을 자동화 하는 것을 꾀하는 것으로 코드 서명 현대화를 마무리 짓는 것이 좋다. 그래야 개발자들이 코드 서명의 안전이나 온전함에 크게 신경을 쓰지 않고도 안전하게 개발 행위를 할 수 있기 때문이다. 그러면서도 안전할 수 있다. 즉 개발자들이 보안에 크게 신경 쓰지 않아야 보안이 유지될 수 있다.
글 : 무랄리 팔라니사미(Murali Palanisamy), CSO, AppViewX
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-10-31] 
