.jpg)
.jpg)
절대로 하지 말아야 할 것은 분명...바로 크리덴셜 정보를 하드코딩하지 않는 것
최소한의 권한을 유지하는 원칙을 고수해야...“데이터는 다시 담을 수 없는 치약과 같아”
[보안뉴스 문가용 기자] 오픈소스 소프트웨어는 이제 개발자들에게 있어 빼놓을 수 없는 요소다. 그리고 오픈소스를 활용하는 모든 개발자들에게 있어 깃허브(GitHub)만큼 유용한 것이 현재로서는 없다시피 한 상황이다. 그래서 수많은 개발자들과 기업들이 깃허브라는 플랫폼에서 각종 프로젝트를 진행 중에 있다. 하지만 깃허브가 보안의 측면에서 안전한 공간일까?
‘그렇다’고 할 수 없다. 특히 최근 들어 깃허브와 연루된 해킹 사고가 점점 더 많이 일어나고 있기도 하다. 이에 따라 깃허브를 더 안전하게 사용하는 방법들도 점점 더 많이 제안되고 있는 상황이다. 이를 본지에서 간략히 정리해 보았다.
절대로 하지 말아야 할 것
코드와 주석 어디에서건 사용자 이름, 비밀번호, 그 외 모든 크리덴셜 정보를 노출시키는 일은 절대로 없어야 한다. 이는 깃허브만이 아니라 그 어떤 리포지터리를 활용할 때도 마찬가지다. 그 어떤 경우에도 크리덴셜을 애플리케이션 내에 하드코딩 하는 건 보안의 측면에서 대단히 위험한 일일 수밖에 없다. 이러한 행위는 반드시 근절되어야 한다.
보안 업체 노비포(KnowBe4)의 CISO인 브라이언 잭(Brian Jack)은 “공공 리포지터리를 사용하고 있는 기업이라면, 코드의 모든 부분이 결국 공개된다는 걸 염두에 두어야 한다”고 강조한다. “비밀번호, 접근 토큰 등 여러 민감한 정보들이 깃허브를 통해 굉장히 많이 공유되고 있습니다. 기본 중 기본이지만 상당히 빈번하게 어겨지고 있는 게 현실입니다.”
그러면서 잭은 “조직 입장에서는 깃허브든, 소셜미디어든, 그 모든 공개 플랫폼에 뭔가를 공유하려고 할 때, 보다 적절한 허가 절차를 거치도록 정책을 마련하는 게 안전하다”고 제안했다.
사람을 가려가며
깃허브에 대해 많은 사람들이 오해하는 것 한 가지는 ‘깃허브는 완전히 열린 공간이므로, 모든 코드가 완전히 공개되어야 한다’는 것이다. 이를 자기의 신념으로 고수하고 있는 건 자유지만, 보안의 측면에서 봤을 때 그렇게까지 권장할 만한 것은 아니다.
보안 업체 앱옴니(AppOmni)의 CEO인 브렌든 오코너(Brendan O'Connor)는 “역할 기반 접근 제어(RBAC)가 정착되어 있지 않다는 걸 수많은 조직들이 간과하고 있다”고 설명한다. “깃허브와 같은 코드 리포지터리에 코드를 공개할 때도 RBAC에 기반을 두어야 합니다. 최소한의 권한을 최소한의 사람들에게 허용해야 한다는 것이죠. 그리고 이 원칙은 RBAC에 근거를 두어야 합니다.”
깃허브에 공유되는 코드가 무엇인지, 어떠한 성질과 중요도를 가지고 있는지, 어떤 팀에서 개발을 이루고 있으며 어떤 개발 단계에 놓여 있는지를 모두 고려해 접근할 수 있는 사람을 최소화 시켜야 한다는 게 오코너의 설명이다. “같은 조직에 있다는 이유만으로 깃허브 코드에 마음대로 들락날락 할 수 있다는 건 생각만 해도 위험한 일이죠.”
관리 주체가 몇 사람인가?
같은 프로젝트더라도 한 사람이 관리하는 것과 여러 사람이 참여하는 것에는 차이가 있다. 특히 보안이라는 관점에서는 차이가 크다. 이에 대해 보안 업체 주니퍼(Juniper)의 무니르 하하드(Mounir Hahad)는 다음과 같이 설명한다.
“깃허브 계정이 한 사람에 의해 관리되고 있는지 여러 사람이 참여하고 있는지 주기적으로 확인할 필요가 있습니다. 즉 프로젝트를 한 사람만 지속적으로 발전시키고 코드를 추가하고 있는 건지, 콘텐츠를 여러 사람이 추가하는 건지 늘 파악해야 한다는 것이죠. 만약 여러 사람이 콘텐츠를 추가하는 시스템이라면, 업데이트나 패치를 무조건적으로 믿어서는 안 됩니다. 무조건 코드 점검을 하고 나서 업데이트를 적용해야 하죠.”
이 부분에 대해서는 보안 업체 설트스택(SaltStack)의 브라이스 라슨(Bryce Larson)도 동의한다. “오픈소스 소프트웨어는 수많은 사람들이 지켜보기 때문에 더 안전한 것이 이론상 맞습니다. 한 사람이 코드를 완전무결하게 검토하고 고칠 수는 없으니까요. 그런데 이 이론은, ‘나 말고도 코드를 점검할 사람이 많다’고 미루게 되면 소용이 없게 됩니다. 그렇기 때문에 오픈소스에 참여하는 사람이라면 일부로라도 시간을 내서 코드 점검을 하는 게 맞습니다.”
K2 사이버 시큐리티(K2 Cyber Security)의 부회장인 티모시 치우(Timothy Chiu)는 “깃허브의 코드를 사용할 때, 인하우스로 비밀리에 진행되는 중요한 사업을 위한 코드처럼 다뤄야 한다”고 말한다. “사운을 건 코드를 짜는 거라면 취약점 점검도 꼼꼼하게 하겠죠? 오픈소스 코드들도 그런 자세로 점검하고 사용해야 한다는 겁니다.”
건강 검진을 주기적으로 하듯
오코너는 “깃허브는 그 자체로 유기체인 것처럼 다뤄야 한다”고 강조한다. “살아 있는 시스템입니다. 환경설정 상태도 항상 바뀌고, 플랫폼 내 문화와 유행도 빠르게 변하죠. 고정적인 정책이나 관습만으로는 실패가 반드시 일어날 수밖에 없습니다. 그래서 깃허브를 안전하게 사용하는 게 어려운 일이 됩니다. 깃허브는 늘 변한다, 그러므로 깃허브 보안도 늘 변해야 한다는 걸 기억하는 것부터 안전은 시작됩니다.”
깃허브가 늘 변한다는 걸 기억한다는 건 무슨 뜻일까? 블랙스톤 로그룹(Blackstone Law Group)의 파트너인 알렉스 우벌리스(Alex Uberlis)는 다음과 같이 설명한다. “깃허브 관리의 골자는 내부에서의 위협과 외부에서의 위협 모두를 최소화 하는 것입니다. 데이터라는 건 치약과 같아서 한 번 튜브 밖으로 나오면 담을 수가 없죠. 깃허브에 있는 코드들도 마찬가지입니다. 한 번 밖으로 삐져나오면 그걸로 끝입니다. 그러니 처음부터 이 튜브에 가해지는 힘을 모니터링하고 조절하는 게 답입니다.”
3줄 요약
1. 깃허브, 오픈소스가 대세가 된 현 시점에서 가장 중요한 플랫폼.
2. 그러나 깃허브 플랫폼이 보안 플랫폼이 아니라는 것을 자주 잊는 듯.
3. 깃허브에도 안전한 사용 규칙 있으니, 이를 준수하는 게 중요.
[국제부 문가용 기자(globoan@boannews.com)]
최소한의 권한을 유지하는 원칙을 고수해야...“데이터는 다시 담을 수 없는 치약과 같아”
[보안뉴스 문가용 기자] 오픈소스 소프트웨어는 이제 개발자들에게 있어 빼놓을 수 없는 요소다. 그리고 오픈소스를 활용하는 모든 개발자들에게 있어 깃허브(GitHub)만큼 유용한 것이 현재로서는 없다시피 한 상황이다. 그래서 수많은 개발자들과 기업들이 깃허브라는 플랫폼에서 각종 프로젝트를 진행 중에 있다. 하지만 깃허브가 보안의 측면에서 안전한 공간일까?
[이미지 = utoimage]
‘그렇다’고 할 수 없다. 특히 최근 들어 깃허브와 연루된 해킹 사고가 점점 더 많이 일어나고 있기도 하다. 이에 따라 깃허브를 더 안전하게 사용하는 방법들도 점점 더 많이 제안되고 있는 상황이다. 이를 본지에서 간략히 정리해 보았다.
절대로 하지 말아야 할 것
코드와 주석 어디에서건 사용자 이름, 비밀번호, 그 외 모든 크리덴셜 정보를 노출시키는 일은 절대로 없어야 한다. 이는 깃허브만이 아니라 그 어떤 리포지터리를 활용할 때도 마찬가지다. 그 어떤 경우에도 크리덴셜을 애플리케이션 내에 하드코딩 하는 건 보안의 측면에서 대단히 위험한 일일 수밖에 없다. 이러한 행위는 반드시 근절되어야 한다.
보안 업체 노비포(KnowBe4)의 CISO인 브라이언 잭(Brian Jack)은 “공공 리포지터리를 사용하고 있는 기업이라면, 코드의 모든 부분이 결국 공개된다는 걸 염두에 두어야 한다”고 강조한다. “비밀번호, 접근 토큰 등 여러 민감한 정보들이 깃허브를 통해 굉장히 많이 공유되고 있습니다. 기본 중 기본이지만 상당히 빈번하게 어겨지고 있는 게 현실입니다.”
그러면서 잭은 “조직 입장에서는 깃허브든, 소셜미디어든, 그 모든 공개 플랫폼에 뭔가를 공유하려고 할 때, 보다 적절한 허가 절차를 거치도록 정책을 마련하는 게 안전하다”고 제안했다.
사람을 가려가며
깃허브에 대해 많은 사람들이 오해하는 것 한 가지는 ‘깃허브는 완전히 열린 공간이므로, 모든 코드가 완전히 공개되어야 한다’는 것이다. 이를 자기의 신념으로 고수하고 있는 건 자유지만, 보안의 측면에서 봤을 때 그렇게까지 권장할 만한 것은 아니다.
보안 업체 앱옴니(AppOmni)의 CEO인 브렌든 오코너(Brendan O'Connor)는 “역할 기반 접근 제어(RBAC)가 정착되어 있지 않다는 걸 수많은 조직들이 간과하고 있다”고 설명한다. “깃허브와 같은 코드 리포지터리에 코드를 공개할 때도 RBAC에 기반을 두어야 합니다. 최소한의 권한을 최소한의 사람들에게 허용해야 한다는 것이죠. 그리고 이 원칙은 RBAC에 근거를 두어야 합니다.”
깃허브에 공유되는 코드가 무엇인지, 어떠한 성질과 중요도를 가지고 있는지, 어떤 팀에서 개발을 이루고 있으며 어떤 개발 단계에 놓여 있는지를 모두 고려해 접근할 수 있는 사람을 최소화 시켜야 한다는 게 오코너의 설명이다. “같은 조직에 있다는 이유만으로 깃허브 코드에 마음대로 들락날락 할 수 있다는 건 생각만 해도 위험한 일이죠.”
관리 주체가 몇 사람인가?
같은 프로젝트더라도 한 사람이 관리하는 것과 여러 사람이 참여하는 것에는 차이가 있다. 특히 보안이라는 관점에서는 차이가 크다. 이에 대해 보안 업체 주니퍼(Juniper)의 무니르 하하드(Mounir Hahad)는 다음과 같이 설명한다.
“깃허브 계정이 한 사람에 의해 관리되고 있는지 여러 사람이 참여하고 있는지 주기적으로 확인할 필요가 있습니다. 즉 프로젝트를 한 사람만 지속적으로 발전시키고 코드를 추가하고 있는 건지, 콘텐츠를 여러 사람이 추가하는 건지 늘 파악해야 한다는 것이죠. 만약 여러 사람이 콘텐츠를 추가하는 시스템이라면, 업데이트나 패치를 무조건적으로 믿어서는 안 됩니다. 무조건 코드 점검을 하고 나서 업데이트를 적용해야 하죠.”
이 부분에 대해서는 보안 업체 설트스택(SaltStack)의 브라이스 라슨(Bryce Larson)도 동의한다. “오픈소스 소프트웨어는 수많은 사람들이 지켜보기 때문에 더 안전한 것이 이론상 맞습니다. 한 사람이 코드를 완전무결하게 검토하고 고칠 수는 없으니까요. 그런데 이 이론은, ‘나 말고도 코드를 점검할 사람이 많다’고 미루게 되면 소용이 없게 됩니다. 그렇기 때문에 오픈소스에 참여하는 사람이라면 일부로라도 시간을 내서 코드 점검을 하는 게 맞습니다.”
K2 사이버 시큐리티(K2 Cyber Security)의 부회장인 티모시 치우(Timothy Chiu)는 “깃허브의 코드를 사용할 때, 인하우스로 비밀리에 진행되는 중요한 사업을 위한 코드처럼 다뤄야 한다”고 말한다. “사운을 건 코드를 짜는 거라면 취약점 점검도 꼼꼼하게 하겠죠? 오픈소스 코드들도 그런 자세로 점검하고 사용해야 한다는 겁니다.”
건강 검진을 주기적으로 하듯
오코너는 “깃허브는 그 자체로 유기체인 것처럼 다뤄야 한다”고 강조한다. “살아 있는 시스템입니다. 환경설정 상태도 항상 바뀌고, 플랫폼 내 문화와 유행도 빠르게 변하죠. 고정적인 정책이나 관습만으로는 실패가 반드시 일어날 수밖에 없습니다. 그래서 깃허브를 안전하게 사용하는 게 어려운 일이 됩니다. 깃허브는 늘 변한다, 그러므로 깃허브 보안도 늘 변해야 한다는 걸 기억하는 것부터 안전은 시작됩니다.”
깃허브가 늘 변한다는 걸 기억한다는 건 무슨 뜻일까? 블랙스톤 로그룹(Blackstone Law Group)의 파트너인 알렉스 우벌리스(Alex Uberlis)는 다음과 같이 설명한다. “깃허브 관리의 골자는 내부에서의 위협과 외부에서의 위협 모두를 최소화 하는 것입니다. 데이터라는 건 치약과 같아서 한 번 튜브 밖으로 나오면 담을 수가 없죠. 깃허브에 있는 코드들도 마찬가지입니다. 한 번 밖으로 삐져나오면 그걸로 끝입니다. 그러니 처음부터 이 튜브에 가해지는 힘을 모니터링하고 조절하는 게 답입니다.”
3줄 요약
1. 깃허브, 오픈소스가 대세가 된 현 시점에서 가장 중요한 플랫폼.
2. 그러나 깃허브 플랫폼이 보안 플랫폼이 아니라는 것을 자주 잊는 듯.
3. 깃허브에도 안전한 사용 규칙 있으니, 이를 준수하는 게 중요.
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] .jpg)
.jpg)
.jpg)
.jpg)
.jpg)
