2020.11.11

ID 프로젝트에 오픈소스 사용하기··· ‘8가지 고려사항’

Susan Morrow | CSO
조직들이 구축 시간 단축과 비용 절감을 바람에 따라 기업 내에서의 오픈소스 사용이 증가하고 있다. ‘기업 오픈소스 현황(The State of Enterprise Open Source)’이라는 제목의 2019년 레드햇 보고서에 따르면 응답자 중 95%가 오픈소스를 ‘전략적으로 중요’하다고 생각하는 것으로 나타났다. 

하지만 기업 환경에서의 오픈소스 적용을 보면 ID 관리(identity management ) 분야는 다소 동떨어져 있다. 이유는 ID 관련 서비스가 설계하고 구축하기에 유독 복잡한 시스템이기 때문일 수 있다. ID 분야에서도 오픈소스를 현명하게 활용하고 보안과 사용성을 유지할 수 있을까?
 
Image Credit : Getty Images Bank

ID 프로젝트를 위해 오픈소스를 선택할 때 8가지 고려사항
오픈소스 사용에 관한 생각에는 두려움, 불확실성, 의심(FUD)이 존재하는 경우가 많다. 그럴 만한 이유가 있다. 2018년의 에퀴팩스(Equifax) 유출이 적절한 사례다. 오픈소스 사용 시 FUD가 사라지지 않는 것이다. 이 사건에는 오픈소스 마젠토 플랫폼에 대해 무차별 대입 공격을 사용하는 사이버 범죄자들이 연루되어 있었다.

오픈소스를 사용해야 하는 이유가 있다. 누군가 기초 작업을 해 놓았기 때문에 사내 개발자가 그 일을 다시 할 필요가 없다. 이론상 여러 사람(오픈소스 커뮤니티)이 코드를 살펴보고 검증했다. 

단 코드가 단위 시험을 통과했다고 볼 수 있지만 기능 시험에서는 이야기가 달라진다. 거기에 문제가 있다. IT 주도 서비스는 다기능 시스템인 경우가 많다. 이런 시스템의 기능 시험, 많은 사용자 여정, 대체 경로는 코드를 꼬이게 만들어 익스플로잇 공격이 발생할 수 있다.

오픈소스 주도 ID 프로젝트에 착수하기 전에 여러 고려사항을 따져보자. 우선, 무엇보다도 중요한 것은 소프트웨어 개발 라이프 사이클(SDLC)이 만족스러운지 여부이다. 오픈소스 코드를 사용한다고 해서 일반적인 SDLC 프로세스에서 예외일 수는 없다. 오픈소스는 수준급 애플리케이션으로 가는 만능 티켓이 아니다. 외부 또는 내부에서 개발된 시스템과 같은 수준의 시험과 유지보수가 필요하다. 고려해야 할 영역은 다음과 같다. 

1. 보안과 블로트(Bloat)
오픈소스 소프트웨어는 코드 블로트(code bloat )에 취약하다. 이런 일이 발생하면 ‘블로트웨어 효과’가 발생하면서 보안 관리가 어려울 수 있다. 코드 라이브러리에 점차 기능이 추가되는 블로트웨어에서는 소프트웨어 분석이 더 어려워지게 된다. 코드가 복잡해지면 맬웨어를 숨기기가 더 쉬워진다. 최근의 예가 옥토퍼스 스캐너 맬웨어이다. 보안 전문가들은 이것을 26개 깃허브 소스코드 저장소에서 발견했다.

오픈소스 라이브러리 중에서도 ID 영역에 있는 것들은 맬웨어에게 탐스러운 표적이다. 저장소는 항상 최신 버전의 오픈소스 코드를 취한다(패치 통합을 위한 모범 사례). 옥토퍼스 스캐너처럼 누군가 맬웨어에 감염되면 업데이트에 이 맬웨어가 통합된다. 이것을 찾아내지 못하면 제품에 맬웨어가 포함되어 고통스러운 역사가 시작된다.

코드에 대한 통제력 부재는 최종 시스템의 취약성 증가로도 이어질 수 있다. 전체를 신중하게 분석하고 시험해야 한다. 이로 인해 오픈소스를 사용하는 시간 절약 측면이 상쇄될 수 있다. 또한 오픈소스 코드가 다시 작성되는 경우 특정 시스템에서 애플리케이션이 망가질 수 있다.

2. 확장성
특히, 소비자용으로 개발된 ID 서비스는 높은 확장성을 요구하는 경우가 많다. 오픈소스 프로젝트를 선택할 때, 확장성은 고려사항 목록의 우선순위를 차지해야 한다.

3. 상호운용성
각종 ID 프로젝트에는 움직이는 부분이 많다. 또 서드파티 구성 요소를 사용하여 중요한 기능을 추가하는 경우가 많다. 예를 들어, 한 소비자용 ID 시스템은 CRA(Credit Reference Agency)를 이용하여 사용자 속성을 검증할 수 있다. 오픈소스는 선택한 서드파티와의 상호운용 능력이 없을 수 있으며, 이로 인해 직접 오픈소스 코드를 확장해야 할 수 있다. 

4. 유연성
오픈소스에 기초한 ID 서비스를 다른 데이터베이스 스토리지로 확장하는 작업, 다양한 속성을 통합하며 다양한 승인 및 인증 옵션을 사용하는 작업, 프로토콜을 해석하는 등의 작업을 얼마나 쉽게 처리할 수 있을까? 오픈소스 커뮤니티가 OIDC CIBA 등의 새로운 표준에 대한 지원을 추가할 때까지 기다려야 하는 경우가 발생할 수 있다. 

5. 미래 경쟁력
기능을 수정할 수 있을까? 요건이 바뀌면서 기능을 변경하고 추가하기가 쉬울까? ID 서비스는 지속적인 우려 대상일 수 있다. 고객 기대치는 시간에 따라 바뀌지만 근간의 서비스는 지속되어야 한다. 특정 오픈소스 라이브러리를 사용하는데 지나치게 몰두한다면 유사한 기능을 제공하는 더 나은 향상된 라이브러리로 옮겨 가기가 어려울 수 있다. 오픈소스가 벤더 록인 버전이 될 수 있다.

6. 지원 및 유지보수
오픈소스 솔루션에 추가적인 지원 패키지가 수반되곤 한다. 오픈소스 사용 효과를 희석시키는 관행일 수 있다. 또 자체 팀이 지원 패키지의 지식 또는 범위를 벗어나는 수준으로 코드를 개발하는 경우 문제가 발생할 수도 있다. 유지보수도 문제가 될 수 있다.

ID 서비스는 디지털 상호작용의 막장에 있으며 보안 분야의 변화무쌍함에 대응해야 한다. 새로운 익스플로잇 공격이 발생하면서 ID 서비스는 시스템 거동을 수정하고 오래된 소프트웨어의 손쉬운 패치를 가능하게 하며 기존 시스템에 새로운 기능을 추가하여 공백을 줄일 수 있어야 한다.

7. ID 전문지식
IT서비스에는 다각적인 전문지식이 필요하다. 여기에는 UI/UX 지식, 심층적인 프라이버시 및 규제 준수에 대한 이해, 광범위한 보안 전문지식이 포함된다. 오픈소스 코드를 사용하는 것은 ID 관련 서비스를 구축하는 일의 일부분일 뿐이다. 잘 설계되고 개발된 ID 시스템은 광범위한 인구에 가장 적합한 플랫폼을 개발하는 전방위적 접근방식이 필요하다. 코드부터 시작하는 것은 잘못된 방법이다. 물론 코드가 올바른 작업 기초를 형성할 수 있다면 많은 문제를 피할 수 있다.

8. 의존성
오픈소스 라이브러리에 의존성이 있을 때가 있다. 즉, 설치할 때 다른 관련 라이브러리가 설치된다. 이런 경우 불필요한 오픈소스 라이브러리가 많아질 수 있다. 

일부 라이브러리의 중요도가 떨어지면서 문제가 될 수 있다. 이런 경우 오픈소스 커뮤니티가 대안을 제시한다. 그래서 새로운 일련의 라이브러리로 전향해야 할 수도 있다. 그렇지 않으면 중요도가 떨어진 라이브러리를 계속 사용하게 되며, 여기에 절대로 해결되지 않을 취약성이 포함되어 있을 수도 있다.

오픈소스를 현명하게 사용하라
ID 서비스는 특성상 매우 역동적이다. ID 서비스가 전자상거래와 고객 기대치를 따라야 하는 경우가 많다. 보안 분야에서는 ID 시스템과 사용자 속성이 표적이 된다. 즉, 시스템이 변화를 처리할 만큼 유연해야 한다.

오픈소스를 사용하기로 선택했다면 주의하고 오픈소스 라이브러리를 적용할 곳을 잘 선택할 필요가 있다. 궁극적으로 ID 시스템의 디자인이 우선적이어야 한다. 오픈소스를 현명하게 선택하는 경우 프로젝트가 강화될 수 있다. 실제로 원하는 기능만 제공하는 라이브러리인지 꼼꼼하게 살펴볼 것을 권한다. 

* Susan Morrow는 사이버보안 및 온라인 ID 분야에 20년 경력을 가진 전문가다. 사용성과 보안의 균형에 관심이 많다. ciokr@idg.co.kr
 



2020.11.11

ID 프로젝트에 오픈소스 사용하기··· ‘8가지 고려사항’

Susan Morrow | CSO
조직들이 구축 시간 단축과 비용 절감을 바람에 따라 기업 내에서의 오픈소스 사용이 증가하고 있다. ‘기업 오픈소스 현황(The State of Enterprise Open Source)’이라는 제목의 2019년 레드햇 보고서에 따르면 응답자 중 95%가 오픈소스를 ‘전략적으로 중요’하다고 생각하는 것으로 나타났다. 

하지만 기업 환경에서의 오픈소스 적용을 보면 ID 관리(identity management ) 분야는 다소 동떨어져 있다. 이유는 ID 관련 서비스가 설계하고 구축하기에 유독 복잡한 시스템이기 때문일 수 있다. ID 분야에서도 오픈소스를 현명하게 활용하고 보안과 사용성을 유지할 수 있을까?
 
Image Credit : Getty Images Bank

ID 프로젝트를 위해 오픈소스를 선택할 때 8가지 고려사항
오픈소스 사용에 관한 생각에는 두려움, 불확실성, 의심(FUD)이 존재하는 경우가 많다. 그럴 만한 이유가 있다. 2018년의 에퀴팩스(Equifax) 유출이 적절한 사례다. 오픈소스 사용 시 FUD가 사라지지 않는 것이다. 이 사건에는 오픈소스 마젠토 플랫폼에 대해 무차별 대입 공격을 사용하는 사이버 범죄자들이 연루되어 있었다.

오픈소스를 사용해야 하는 이유가 있다. 누군가 기초 작업을 해 놓았기 때문에 사내 개발자가 그 일을 다시 할 필요가 없다. 이론상 여러 사람(오픈소스 커뮤니티)이 코드를 살펴보고 검증했다. 

단 코드가 단위 시험을 통과했다고 볼 수 있지만 기능 시험에서는 이야기가 달라진다. 거기에 문제가 있다. IT 주도 서비스는 다기능 시스템인 경우가 많다. 이런 시스템의 기능 시험, 많은 사용자 여정, 대체 경로는 코드를 꼬이게 만들어 익스플로잇 공격이 발생할 수 있다.

오픈소스 주도 ID 프로젝트에 착수하기 전에 여러 고려사항을 따져보자. 우선, 무엇보다도 중요한 것은 소프트웨어 개발 라이프 사이클(SDLC)이 만족스러운지 여부이다. 오픈소스 코드를 사용한다고 해서 일반적인 SDLC 프로세스에서 예외일 수는 없다. 오픈소스는 수준급 애플리케이션으로 가는 만능 티켓이 아니다. 외부 또는 내부에서 개발된 시스템과 같은 수준의 시험과 유지보수가 필요하다. 고려해야 할 영역은 다음과 같다. 

1. 보안과 블로트(Bloat)
오픈소스 소프트웨어는 코드 블로트(code bloat )에 취약하다. 이런 일이 발생하면 ‘블로트웨어 효과’가 발생하면서 보안 관리가 어려울 수 있다. 코드 라이브러리에 점차 기능이 추가되는 블로트웨어에서는 소프트웨어 분석이 더 어려워지게 된다. 코드가 복잡해지면 맬웨어를 숨기기가 더 쉬워진다. 최근의 예가 옥토퍼스 스캐너 맬웨어이다. 보안 전문가들은 이것을 26개 깃허브 소스코드 저장소에서 발견했다.

오픈소스 라이브러리 중에서도 ID 영역에 있는 것들은 맬웨어에게 탐스러운 표적이다. 저장소는 항상 최신 버전의 오픈소스 코드를 취한다(패치 통합을 위한 모범 사례). 옥토퍼스 스캐너처럼 누군가 맬웨어에 감염되면 업데이트에 이 맬웨어가 통합된다. 이것을 찾아내지 못하면 제품에 맬웨어가 포함되어 고통스러운 역사가 시작된다.

코드에 대한 통제력 부재는 최종 시스템의 취약성 증가로도 이어질 수 있다. 전체를 신중하게 분석하고 시험해야 한다. 이로 인해 오픈소스를 사용하는 시간 절약 측면이 상쇄될 수 있다. 또한 오픈소스 코드가 다시 작성되는 경우 특정 시스템에서 애플리케이션이 망가질 수 있다.

2. 확장성
특히, 소비자용으로 개발된 ID 서비스는 높은 확장성을 요구하는 경우가 많다. 오픈소스 프로젝트를 선택할 때, 확장성은 고려사항 목록의 우선순위를 차지해야 한다.

3. 상호운용성
각종 ID 프로젝트에는 움직이는 부분이 많다. 또 서드파티 구성 요소를 사용하여 중요한 기능을 추가하는 경우가 많다. 예를 들어, 한 소비자용 ID 시스템은 CRA(Credit Reference Agency)를 이용하여 사용자 속성을 검증할 수 있다. 오픈소스는 선택한 서드파티와의 상호운용 능력이 없을 수 있으며, 이로 인해 직접 오픈소스 코드를 확장해야 할 수 있다. 

4. 유연성
오픈소스에 기초한 ID 서비스를 다른 데이터베이스 스토리지로 확장하는 작업, 다양한 속성을 통합하며 다양한 승인 및 인증 옵션을 사용하는 작업, 프로토콜을 해석하는 등의 작업을 얼마나 쉽게 처리할 수 있을까? 오픈소스 커뮤니티가 OIDC CIBA 등의 새로운 표준에 대한 지원을 추가할 때까지 기다려야 하는 경우가 발생할 수 있다. 

5. 미래 경쟁력
기능을 수정할 수 있을까? 요건이 바뀌면서 기능을 변경하고 추가하기가 쉬울까? ID 서비스는 지속적인 우려 대상일 수 있다. 고객 기대치는 시간에 따라 바뀌지만 근간의 서비스는 지속되어야 한다. 특정 오픈소스 라이브러리를 사용하는데 지나치게 몰두한다면 유사한 기능을 제공하는 더 나은 향상된 라이브러리로 옮겨 가기가 어려울 수 있다. 오픈소스가 벤더 록인 버전이 될 수 있다.

6. 지원 및 유지보수
오픈소스 솔루션에 추가적인 지원 패키지가 수반되곤 한다. 오픈소스 사용 효과를 희석시키는 관행일 수 있다. 또 자체 팀이 지원 패키지의 지식 또는 범위를 벗어나는 수준으로 코드를 개발하는 경우 문제가 발생할 수도 있다. 유지보수도 문제가 될 수 있다.

ID 서비스는 디지털 상호작용의 막장에 있으며 보안 분야의 변화무쌍함에 대응해야 한다. 새로운 익스플로잇 공격이 발생하면서 ID 서비스는 시스템 거동을 수정하고 오래된 소프트웨어의 손쉬운 패치를 가능하게 하며 기존 시스템에 새로운 기능을 추가하여 공백을 줄일 수 있어야 한다.

7. ID 전문지식
IT서비스에는 다각적인 전문지식이 필요하다. 여기에는 UI/UX 지식, 심층적인 프라이버시 및 규제 준수에 대한 이해, 광범위한 보안 전문지식이 포함된다. 오픈소스 코드를 사용하는 것은 ID 관련 서비스를 구축하는 일의 일부분일 뿐이다. 잘 설계되고 개발된 ID 시스템은 광범위한 인구에 가장 적합한 플랫폼을 개발하는 전방위적 접근방식이 필요하다. 코드부터 시작하는 것은 잘못된 방법이다. 물론 코드가 올바른 작업 기초를 형성할 수 있다면 많은 문제를 피할 수 있다.

8. 의존성
오픈소스 라이브러리에 의존성이 있을 때가 있다. 즉, 설치할 때 다른 관련 라이브러리가 설치된다. 이런 경우 불필요한 오픈소스 라이브러리가 많아질 수 있다. 

일부 라이브러리의 중요도가 떨어지면서 문제가 될 수 있다. 이런 경우 오픈소스 커뮤니티가 대안을 제시한다. 그래서 새로운 일련의 라이브러리로 전향해야 할 수도 있다. 그렇지 않으면 중요도가 떨어진 라이브러리를 계속 사용하게 되며, 여기에 절대로 해결되지 않을 취약성이 포함되어 있을 수도 있다.

오픈소스를 현명하게 사용하라
ID 서비스는 특성상 매우 역동적이다. ID 서비스가 전자상거래와 고객 기대치를 따라야 하는 경우가 많다. 보안 분야에서는 ID 시스템과 사용자 속성이 표적이 된다. 즉, 시스템이 변화를 처리할 만큼 유연해야 한다.

오픈소스를 사용하기로 선택했다면 주의하고 오픈소스 라이브러리를 적용할 곳을 잘 선택할 필요가 있다. 궁극적으로 ID 시스템의 디자인이 우선적이어야 한다. 오픈소스를 현명하게 선택하는 경우 프로젝트가 강화될 수 있다. 실제로 원하는 기능만 제공하는 라이브러리인지 꼼꼼하게 살펴볼 것을 권한다. 

* Susan Morrow는 사이버보안 및 온라인 ID 분야에 20년 경력을 가진 전문가다. 사용성과 보안의 균형에 관심이 많다. ciokr@idg.co.kr
 

X