.jpg)
이제 이중인증/다중인증은 선택이 아니라 필수다. 물론 사용자가 좀 귀찮아지긴 한다. 그래서 기업들이 과감히 도입하지 못한다. 이해 못할 건 아니지만, 이미 너무 많은 시간이 지나갔다. 이제는 조금 서둘러도 되는 시기다.
[보안뉴스 문정후 기자] 지난 5월 깃허브(GitHub)는 소프트웨어 보안을 향상시키기 위한 중요한 첫 걸음을 뗐다. 모든 코드 리포지터리 컨트리뷰터들에게 2023년 말까지는 반드시 이중인증을 도입해야 한다고 규정을 새로 정해 발표한 것이다. 이중인증의 강제라니, 보안 전문가 입장에서는 환영해 마지 않을 변화이지만 그럼에도 마음 한 쪽에 의문이 하나 생기지 않을 수 없다. 왜 굳이 2023년까지 기다려야 하는가?
완전무결한 건 아니지만 다중인증으로 보호된 계정은 그렇지 않은 계정보다 훨씬 안전한 게 사실이다. 게다가 소프트웨어 공급망은 너무나 취약하며, 그 중에서도 깃허브는 너무나 매력적인 표적일 수밖에 없다. 이런 상황에서 왜 굳이 1년을 더 기다려야 하는지 알 수가 없다. 다중인증이라는 게 최신식 신기술이라 부작용이 잔뜩 잠재해 있는 것도 아닌데 말이다. 내년까지 기다리지 말고 깃허브를 사용하는 벤더사나 소프트웨어 개발자들 측에서 미리 다중인증을 도입하는 건 어떨까.
공급망 공격이라는 위협의 증가
최근의 소프트웨어 공급망 공격은 주로 계정 탈취 공격을 통해 나타난다. 예를 들면 다음과 같다.
1) 공격자가 깃허브나 PyPI와 같은 코드/패키지 공유 사이트에 접속한다.
2) 계정을 탈취한다.
3) 탈취한 계정을 가지고 리포지터리에 악성 코드를 삽입한다.
4) 3)번 과정은 마치 정상적인 개발자나 리포지터리 관리자가 실시한 정상적인 업데이트로 보인다.
5) 악성코드가 퍼진다.
깃허브는 세계에서 가장 큰 소프트웨어 개발 플랫폼이다. 8300만 개발자들이 이 플랫폼에서 활동하며, 2억 개 이상의 리포지터리가 존재한다. 개발자들은 깃허브의 리포지터리를 굉장히 신뢰하는 편이며, 따라서 자신들의 소프트웨어 개발 프로젝트에 적극 활용한다. 그렇기 때문에 오염된 깃허브 리포지터리 하나가 수많은 오픈소스와 더 많은 소프트웨어들을 오염시킬 수 있다. 소프트웨어가 개발되고 공급되는 프로세스 자체가 망가지는 것이다.
소프트웨어 생태계의 보호
필자는 다중인증 도입을 위해 더 이상 기다릴 필요가 없다는 의견이다. 다중인증의 완벽성을 찬양하려는 게 아니다. 세상에 완벽한 보안 장치가 어디 있나. 다만 비밀번호 하나로 뭔가를 보호하는 것보다, 다중인증으로 보호하는 게 훨씬 강력하고 효과가 좋다는 걸 강조하고 싶은 것이다. 공격자들 입장에서 공격 난이도가 높고 낮은 건 공격 대상을 결정하는 데에 필수적으로 고민해야 하는 요소다. 공격자의 심리가 그러한데 굳이 비밀번호를 고집할 이유가 없다.
다중인증 외에도 소프트웨어 공급망을 강화할 수 있는 방안들이 여러 개 있는데, 이 중 몇 가지를 정리하면 다음과 같다.
1) 소프트웨어 구성 분석(software composition analysis, SCA) : 오픈소스 소프트웨어의 보안성, 라이선스 준수, 코드 품질 등의 관리를 자동으로 하게 하는 기술을 말한다. 클라우드 네이티브 애플리케이션들의 사용량과 데브옵스/데브섹옵스의 도입률이 증가하면서 오픈소스 코드를 예전처럼 수동으로 검사하는 건 불가능해졌다.
2) 소프트웨어 원료표(software bill of materials, SBOM) : SBOM은 소프트웨어 구성 요소들과 디펜던시들을 기계가 읽을 수 있는 신호로 표기한 ‘원자재 목록’을 말한다. 하위 요소들이 서로 어떠한 관계를 형성하고 있는지도 나타낸다. SBOM을 통해 오픈소스를 안전하게 활용할 수 있게 되고, 오픈소스가 주는 온갖 이점을 누릴 수도 있게 된다.
3) 패스워드리스(passwordless) : 지난 수십 년 동안 우리의 컴퓨터와 IT 시스템을 보호했던 비밀번호는 더 이상 안전한 장치가 아니다. 이제 보내줘야 할 때가 됐다. 다중인증이라고 하면 보통 비밀번호를 하나 넣고, 그 다음의 인증 요소들을 논하는데, 사실 이런 식으로라도 비밀번호를 고집하는 것도 그리 좋은 생각은 아니다. 약하디 약한 보안 장치인 비밀번호를 계속 가져감으로써 다중인증을 굳이 약화시킬 필요가 없지 않은가?
패스워드리스는 생각보다 오래 전부터 주장되어 온 보안 기법 중 하나지만 그리 큰 힘을 받지는 못했었다. 하지만 최근 애플, 구글, MS 등 IT 업계의 거인들이 패스워드리스를 주장하면서 이 움직임에 동참하는 사람들이 늘어났다. 비밀번호 없는 세상을 상상하는 게 지금으로서는 쉬운 게 아니겠지만(그래서 거부감이 있을 수도 있지만) 이미 전 세계 수억 대의 장비가 비밀번호 없이 보호 받고 있다. 비밀번호와의 작별을 받아들여야 할 때다.
비밀번호 없는 다중인증이라고 한다면 물리 보안 키, 특수 인증 앱, 생체 인증 정보 등 보다 안전하고 쉬운 활용이 가능한 요소들로 구성되는 것이 보통이다. 이 단단하고 안전한 요소들을 두고 비밀번호를 고집하고 있는 게 현재 우리가 말하는 다중인증이다.
비밀번호는 문제 없지만, 비밀번호를 사용하고 관리하는 방법에 문제가 있다는 주장들이 있다는 것을 알고 있다. 필자는 그것이 결국 말장난에 불과한 주장이라고 생각한다. 문제는 결국 비밀번호 그 자체다. 이론상으로만 안전하고 현실에서는 도무지 그 안전성이 발휘되지 않는다면, 그건 보안 장치로서 가치가 없다는 뜻이다. 보안은 환상에 존재하는 학문이 아니라 실존적인 것이며, 우리의 생활이다.
그러므로 깃허브의 다중인증 도입을 제한 시간을 애써 기다릴 필요가 없다. 지금이라도 도입하되, 비밀번호를 사용하지 않는 쪽으로 가는 게 효과적일 것이다. 깃허브를 활발히 이용하여 소프트웨어를 개발하는 사람들이라면 기업이나 사람이라면 더더욱 그렇다. 깃허브가 빨리 움직일 수 없다면, 우리라도 그렇게 하자.
글 : 케빈 델라니(Kevin Delaney), 엔지니어링 국장, Security Compass
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스 문정후 기자] 지난 5월 깃허브(GitHub)는 소프트웨어 보안을 향상시키기 위한 중요한 첫 걸음을 뗐다. 모든 코드 리포지터리 컨트리뷰터들에게 2023년 말까지는 반드시 이중인증을 도입해야 한다고 규정을 새로 정해 발표한 것이다. 이중인증의 강제라니, 보안 전문가 입장에서는 환영해 마지 않을 변화이지만 그럼에도 마음 한 쪽에 의문이 하나 생기지 않을 수 없다. 왜 굳이 2023년까지 기다려야 하는가?
[이미지 = utoimage]
완전무결한 건 아니지만 다중인증으로 보호된 계정은 그렇지 않은 계정보다 훨씬 안전한 게 사실이다. 게다가 소프트웨어 공급망은 너무나 취약하며, 그 중에서도 깃허브는 너무나 매력적인 표적일 수밖에 없다. 이런 상황에서 왜 굳이 1년을 더 기다려야 하는지 알 수가 없다. 다중인증이라는 게 최신식 신기술이라 부작용이 잔뜩 잠재해 있는 것도 아닌데 말이다. 내년까지 기다리지 말고 깃허브를 사용하는 벤더사나 소프트웨어 개발자들 측에서 미리 다중인증을 도입하는 건 어떨까.
공급망 공격이라는 위협의 증가
최근의 소프트웨어 공급망 공격은 주로 계정 탈취 공격을 통해 나타난다. 예를 들면 다음과 같다.
1) 공격자가 깃허브나 PyPI와 같은 코드/패키지 공유 사이트에 접속한다.
2) 계정을 탈취한다.
3) 탈취한 계정을 가지고 리포지터리에 악성 코드를 삽입한다.
4) 3)번 과정은 마치 정상적인 개발자나 리포지터리 관리자가 실시한 정상적인 업데이트로 보인다.
5) 악성코드가 퍼진다.
깃허브는 세계에서 가장 큰 소프트웨어 개발 플랫폼이다. 8300만 개발자들이 이 플랫폼에서 활동하며, 2억 개 이상의 리포지터리가 존재한다. 개발자들은 깃허브의 리포지터리를 굉장히 신뢰하는 편이며, 따라서 자신들의 소프트웨어 개발 프로젝트에 적극 활용한다. 그렇기 때문에 오염된 깃허브 리포지터리 하나가 수많은 오픈소스와 더 많은 소프트웨어들을 오염시킬 수 있다. 소프트웨어가 개발되고 공급되는 프로세스 자체가 망가지는 것이다.
소프트웨어 생태계의 보호
필자는 다중인증 도입을 위해 더 이상 기다릴 필요가 없다는 의견이다. 다중인증의 완벽성을 찬양하려는 게 아니다. 세상에 완벽한 보안 장치가 어디 있나. 다만 비밀번호 하나로 뭔가를 보호하는 것보다, 다중인증으로 보호하는 게 훨씬 강력하고 효과가 좋다는 걸 강조하고 싶은 것이다. 공격자들 입장에서 공격 난이도가 높고 낮은 건 공격 대상을 결정하는 데에 필수적으로 고민해야 하는 요소다. 공격자의 심리가 그러한데 굳이 비밀번호를 고집할 이유가 없다.
다중인증 외에도 소프트웨어 공급망을 강화할 수 있는 방안들이 여러 개 있는데, 이 중 몇 가지를 정리하면 다음과 같다.
1) 소프트웨어 구성 분석(software composition analysis, SCA) : 오픈소스 소프트웨어의 보안성, 라이선스 준수, 코드 품질 등의 관리를 자동으로 하게 하는 기술을 말한다. 클라우드 네이티브 애플리케이션들의 사용량과 데브옵스/데브섹옵스의 도입률이 증가하면서 오픈소스 코드를 예전처럼 수동으로 검사하는 건 불가능해졌다.
2) 소프트웨어 원료표(software bill of materials, SBOM) : SBOM은 소프트웨어 구성 요소들과 디펜던시들을 기계가 읽을 수 있는 신호로 표기한 ‘원자재 목록’을 말한다. 하위 요소들이 서로 어떠한 관계를 형성하고 있는지도 나타낸다. SBOM을 통해 오픈소스를 안전하게 활용할 수 있게 되고, 오픈소스가 주는 온갖 이점을 누릴 수도 있게 된다.
3) 패스워드리스(passwordless) : 지난 수십 년 동안 우리의 컴퓨터와 IT 시스템을 보호했던 비밀번호는 더 이상 안전한 장치가 아니다. 이제 보내줘야 할 때가 됐다. 다중인증이라고 하면 보통 비밀번호를 하나 넣고, 그 다음의 인증 요소들을 논하는데, 사실 이런 식으로라도 비밀번호를 고집하는 것도 그리 좋은 생각은 아니다. 약하디 약한 보안 장치인 비밀번호를 계속 가져감으로써 다중인증을 굳이 약화시킬 필요가 없지 않은가?
패스워드리스는 생각보다 오래 전부터 주장되어 온 보안 기법 중 하나지만 그리 큰 힘을 받지는 못했었다. 하지만 최근 애플, 구글, MS 등 IT 업계의 거인들이 패스워드리스를 주장하면서 이 움직임에 동참하는 사람들이 늘어났다. 비밀번호 없는 세상을 상상하는 게 지금으로서는 쉬운 게 아니겠지만(그래서 거부감이 있을 수도 있지만) 이미 전 세계 수억 대의 장비가 비밀번호 없이 보호 받고 있다. 비밀번호와의 작별을 받아들여야 할 때다.
비밀번호 없는 다중인증이라고 한다면 물리 보안 키, 특수 인증 앱, 생체 인증 정보 등 보다 안전하고 쉬운 활용이 가능한 요소들로 구성되는 것이 보통이다. 이 단단하고 안전한 요소들을 두고 비밀번호를 고집하고 있는 게 현재 우리가 말하는 다중인증이다.
비밀번호는 문제 없지만, 비밀번호를 사용하고 관리하는 방법에 문제가 있다는 주장들이 있다는 것을 알고 있다. 필자는 그것이 결국 말장난에 불과한 주장이라고 생각한다. 문제는 결국 비밀번호 그 자체다. 이론상으로만 안전하고 현실에서는 도무지 그 안전성이 발휘되지 않는다면, 그건 보안 장치로서 가치가 없다는 뜻이다. 보안은 환상에 존재하는 학문이 아니라 실존적인 것이며, 우리의 생활이다.
그러므로 깃허브의 다중인증 도입을 제한 시간을 애써 기다릴 필요가 없다. 지금이라도 도입하되, 비밀번호를 사용하지 않는 쪽으로 가는 게 효과적일 것이다. 깃허브를 활발히 이용하여 소프트웨어를 개발하는 사람들이라면 기업이나 사람이라면 더더욱 그렇다. 깃허브가 빨리 움직일 수 없다면, 우리라도 그렇게 하자.
글 : 케빈 델라니(Kevin Delaney), 엔지니어링 국장, Security Compass
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] .jpg)
.jpg)
.jpg)
.jpg)
.jpg)
