[컬럼] 오픈소스 취약성, GDPR에 영향 미친다
상태바
[컬럼] 오픈소스 취약성, GDPR에 영향 미친다
  • 데이터넷
  • 승인 2018.04.03 15:56
  • 댓글 0
이 기사를 공유합니다

에퀴팩스, 오픈소스 취약점 방치해 개인정보 유출…GDPR 대응 위해 오픈소스 관리 나서야
<강태진 인사이너리 대표>

1995년 채택된 ‘데이터 보호 법규 95/46/EC(Data Protection Directive)’는 유럽연합(EU)이 모든 회원국에 적용되는 통일된 데이터 프라이버시 규칙을 세우기 위한 시도였다.

1996년 미국 의회는 구체적인 데이터 프라이버시와 보안 보호 대책을 제공하기 위해 연방의료보험통상책임법(HIPAA)을 제정했다. 이어 2003년에는 캘리포니아 주 의회가 개인정보와 프라이버시를 규제하는 법안 SB1386을 통과시켰다. 새로운 법규가 입안되고 제정, 시행되면서 다국적 비즈니스를 펼치는 기업들은 해당 주의 특정한 요구 조건에 맞춰 데이터 프라이버시와 보호 방안을 조정해야 하는 과제를 안고 있다.

EU는 다음달 25일 ‘개인데이터보호법(GDPR)’을 발효하게 된다. 이 법은 2016년에 승인돼 2년 간의 유예 기간을 거쳤다. GDPR은 EU 소속 나라들에 위치하거나 그곳에서 비즈니스를 하는 기업이나 기관뿐 아니라, 지리적 위치와는 상관없이 EU 거주자들의 개인 데이터를 수집하고 처리하는 기업이나 기관에도 적용된다.

캘리포니아에서 비즈니스를 하는 기업이 해당 주법이 요구하는 데이터 보호 규칙을 따라야 하듯, EU 주민의 데이터를 처리하는 기업은 그보다 더 엄격한 데이터 프라이버시와 보호를 요구하는 GDPR의 요구 사항에 따라야 할 것이다.

개인정보 보호 규제 내용 구체화한 GDPR

공식 웹사이트 www.eugdpr.org에 따르면 GDPR은 ‘점점 더 데이터가 중요시되는 사회에서 EU 시민들을 프라이버시 침해와 개인정보 유출 사고로부터 보호하기 위한 법’이다.

GDPR의 적용 범위는 넓다. EU의 컨트롤러(Controller)와 프로세서(Processor)가 처리하는 개인 데이터에 적용되며, 그 처리가 EU에서 일어나든, EU 밖에서 일어나든 동일하게 적용된다. 여기에서 컨트롤러는 개인 데이터를 수집하고, 이용하는 주체를 가리키며, 프로세서는 컨트롤러를 대신해 개인 데이터를 처리, 분석, 가공하는 주체를 지칭한다.

GDPR 위반에 따른 벌금은 결코 무시할 만한 규모가 아니다. GDPR을 위반한 기업이나 기관은 1년 매출 총액의 4%, 혹은 2000만 유로까지(더 큰 쪽이 해당된다) 벌금을 부과 받을 수 있다.

GDPR은 OECD의 ‘프라이버시 보호와 개인 데이터의 국경 유통에 관한 가이드라인(95/46/EC)’을 비롯해 다른 주요 프라이버시 관련 규칙을 망라하고 있다. 이전까지 적용돼 온 ‘데이버보호법규(Directive)’는 프라이버시 보호라는 대명제만 명시하고, 어떻게 그런 목표를 달성할지는 각 EU 회원국들의 자율에 맡긴 반면, GDPR은 그 구체적인 규제 내용까지 EU의 모든 회원국에 일괄 적용한다는 점에서 더 엄격하다.

에퀴팩스, GDPR 적용 받으면 벌금 1270억원

2017년에 터진 에퀴팩스의 데이터 유출 사건은 데이터 보호의 문제와 더불어, 오픈소스 코드, 혹은 코드의 구성 요소들의 이용을 둘러싼 여러 시사점을 제기한다. 미국의 3대 개인 신용평가 기관 중 하나인 에퀴팩스는, 보안 취약성이 발견돼 제대로 수정된 아파치 스트러츠(Apache Struts) 소프트웨어 버전을 설치했더라면 데이터 유출 사고를 피할 수 있었을 것이다. 취약점이 개선된 업데이트 버전은 공격이 벌어지기 몇 달 전부터 충분히 내려 받을 수 있었다.

만약 GDPR이 발효된 상황에서 에퀴팩스 사건이 터졌다면 그에 따른 과징금은 상당했을 것이다. 발표가 한동안 연기됐던 에퀴팩스의 2017년 수입에 근거한다면, 약 30억 달러에 이르는 매출액의 4%는 무려 1억2000만 달러(약 1270억원)나 된다. EU에서 비즈니스를 하면서 보안의 취약성을 감추고 쉬쉬하던 시대는 끝났다.

오픈소스 취약점 ‘낮게 달려 따기 좋은 과일’

요즘 작성되는 소프트웨어의 90% 이상은 오픈소스 코드를 포함하고 있다. 그러한 코드는 운영체제에, 네트워크 플랫폼에, 그리고 애플리케이션에서 사용된다. 이런 흐름은 앞으로 더 뚜렷해질 것이다. 개발자들은 오픈소스를 활용함으로써 제작 원가는 낮추면서도 새로운 기술 혁신을 신속하게 적용할 수 있기 때문이다.

소프트웨어 코드가 독점이든 오픈소스든 보안상의 취약점을 안고 있게 마련이다. 오픈소스 소프트웨어는 그 투명성 덕택에 비공개된 독점 소프트웨어에 견주어 더 뛰어난 설계 구조를 지니고 있을 때가 많다. 그리고 소스가 공개돼 있고 자유롭게 개조해 사용할 수 있는 유연성 때문에 광범위하게 활용되고 있다.

이는 오픈소스 코드의 보안 취약성이 다수의 애플리케이션과 플랫폼에 걸쳐 존재할 수 있다는 뜻이다. 그 결과 오픈소스 소프트웨어의 취약성은 해커들이 표적으로 삼아 공격하기 좋은 ‘낮게 달려 따기 좋은 과일’로 여겨져 왔다.

우리 생활의 거의 모든 분야에서 사용되고 있는 소프트웨어 인프라의 보안성을 확보하는 임무는 점점 더 어렵고 복잡한 과제가 되고 있다. 다수의 내·외부 팀에 의해 개발과 개선을 거듭하며 복잡해진 소프트웨어의 이력관리, 소스코드가 제공되지 않는 외부에서 유입된 소프트웨어, 이들이 포함하고 있는 오픈소스 소프트웨어의 취약점에 대한 인식 부족 같은 여러 장벽 때문이다.

사이버 보안 보험으로 GDPR 대응 못해

오픈소스 소프트웨어의 취약성으로 인한 잠재적 데이터 분실, 그리고 그에 따른 EU의 부담스러운 과징금의 위험을 줄이려면 어떻게 해야 할까?

많은 기업들은 소프트웨어 인프라의 보안성을 확보하는 일이 해마다 더 어려워진다는 사실을 절감한다. 그래서 어떤 기관들은 보안 사고로 인한 재무 손실을 줄이기 위해 사이버보안 보험에 가입하기도 한다. 프라이스워터하우스쿠퍼스(PwC)는 2020년까지 기업들이 사이버보안 보험에 75억달러를 지출할 것으로 예상했다.

그러나 법조계와 보험계의 전문가들은 GDPR과 관련된 한 사이버보안 보험은 한계가 있다고 지적해 왔다. 예를 들면 슈스미스 LLP는 2017년 11월 법률 관련 정보 사이트인 렉솔로지에 기고한 글에서, 다국적 기업과 기관들은 특히 사이버 공격이 거의 일상이 돼버린 요즘 현실에서, 보안 사고가 터졌을 경우 매출총액의 4%를 기꺼이 커버해 줄 사이버보안 보험 회사를 찾기는 지극히 어려울 것이라고 전망했다.

오픈소스 구성요소 파악·관리해야

기업이 오픈소스의 취약성을 개선하거나 차단할 수 있는 또 다른 방법은 해당 소프트웨어를 구입하기 전이나 뒤에, 그 소프트웨어에 숨어 있는 오픈소스 코드의 구성 요소를 정확히 파악하는 일이다. 그러나 이것은 결코 쉬운 일이 아니다. 소프트웨어를 공급하는 업체들이 소스코드를 제공하지 않을뿐 아니라 납품하는 소프트웨어가 포함하고 있는 오픈소스 목록 조차 제공하지 않는 경우가 많기 때문이다.

다행히 새로운 유형의 지문 기반의 바이너리 코드 스캐너들이 나와 이런 어려움을 덜어준다. 이런 솔루션을 이용해 기업들은 자사의 소프트웨어와 펌웨어를 바이너리 코드로 간단히 스캔할 수 있다. 리버스엔지니어링 기법으로 오픈소스 코드를 찾아낸 뒤 이를 다시 스캔하는 기존 작업은 소요 시간과 노력도 만만치 않을 뿐 아니라 정확도도 떨어진다.

어떤 오픈소스 코드 요소들이 현재, 혹은 앞으로 사용할 코드에 들어 있는지 정확히 파악함으로써, 기업의 IT 부서는 해당 소프트웨어에 대한 투자 위험을 평가하고, 그것을 최신 오픈소스 버전들로 업데이트함으로써 위험성을 미리 줄일 수 있다. 효과적인 오픈소스 업데이트 모델은 데이터 보안을 보장하고 기업 차원의 잠재적 손실을 최소화하기 위한 최우선 과제가 돼야 한다.

오픈소스 소프트웨어 개발과 이용은 현대 비즈니스의 거스를 수 없는 대세이다. 그리고 EU 시장의 막대한 중요성을 고려하면, 기업들은 GDPR의 요구 사항을 준수하는 쪽으로 가닥을 잡아야 한다. 따라서 소프트웨어 개발팀과 IT 팀들은 좀 더 면밀하게 GDPR의 내용과 의미, 예상되는 파장을 조사하고 재평가하는 한편, 자사가 클라이언트 데이터를 어떻게 수집하고, 관리하고, 보호하는지 그 정책과 절차를 복기해볼 필요가 있다.

사이버보안 보험 회사들이 제시하는 단기적인 위기 절감 대책은 얼마나 실효성이 있는지도 검토해야 한다. 그와 함께 오픈소스의 보안 취약성에 적절히 대응할 수 있는 대책과 계획, 절차는 어떤지도 짚어보는 것이 현명하다.



댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.