조직 계층 구조 내에서 소프트웨어 다시 생각하기

이 기사의 일부 내용은 Dark Reading에 게재되었으며, 업데이트를 거쳐 이곳에 다시 게시되었습니다.

‍

조직 내에서 누가 누구에게 보고하는지를 정의하는 운영 보고서나 조직도를 본 적이 있을 것입니다. 흔히 조직도라고 불리는 이 도구는 누가 누구의 상사이고 누가 누구의 부하 직원인지 파악하는 데 유용합니다. 예를 들어, 일반적인 조직도에서 코딩 그룹의 책임자는 제품 개발 이사에게 보고하고, 이사는 다시 혁신 담당 부사장에게 보고하는 식입니다. 회사 구조 내에서 권한의 계층은 위아래로 이어집니다. 조직도 속에서 자신의 작은 위치를 찾아본 적이 없는 사람이 있을까요?

인간이 계층과 구조에 매료되는 것은 놀라운 일이 아닙니다. 역사적으로 이는 고대부터 위험한 세상에서 인류가 생존할 수 있었던 비결이었습니다. 우리는 가장 강하거나 빠른 존재는 아니었지만, 팀을 이루어 각자의 역할과 책임을 다함으로써 가족과 부족을 지키고 번영할 수 있었습니다. 현대의 조직도는 사실 그러한 고대의 성공 방식이 확장된 형태입니다.

하지만 규모나 다른 요인과 관계없이 거의 모든 조직도가 가진 공통점이 하나 있습니다. 대부분의 경우, 조직도상의 모든 구성 요소는 사람이나 사람들의 집단을 나타냅니다. 아직 기계가 인간을 관리하는 단계는 아니기에, 현재 조직도는 전적으로 인간의 영역입니다. 그렇다면 우리의 소프트웨어에도 조직 계층이 필요할까요?

물론 소프트웨어를 회사 조직도에 추가하자는 뜻은 아닙니다. 앱을 상사로 두고 싶은 사람은 없을 테니까요. 앱에게 연봉 인상을 요구할 수는 없지 않습니까? 하지만 오늘날 애플리케이션과 프로그램이 직면한 위협 환경은 우리 조상들이 마주했던 위험한 환경과 다르지 않습니다. 앱과 소프트웨어의 책임을 엄격한 계층 구조 내에서 정의하고 최소 권한 원칙을 적용함으로써, 우리는 이 파괴적이고 거친 위협 환경 속에서도 소프트웨어가 안전하게 생존하고 성장할 수 있도록 보장할 수 있습니다.

앱과 소프트웨어를 향한 공격, 사상 최고치 기록

소프트웨어를 위한 더 나은 조직 계층 구조가 필요한 이유를 이해하려면 먼저 위협 환경을 파악해야 합니다. 오늘날 공격자들과 그들이 사용하는 봇 및 자동화 소프트웨어는 방어 체계의 작은 틈이라도 끊임없이 노리고 있습니다. 피싱과 같은 인간을 대상으로 한 공격도 여전히 존재하지만, 숙련된 해커들은 공격의 대부분을 소프트웨어로 전환했습니다.

모든 소프트웨어가 표적이 되고 있지만, 가장 성공적인 공격은 애플리케이션 프로그래밍 인터페이스(API)를 대상으로 이루어집니다. API는 개발자가 앱과 프로그램을 위해 작지만 중요한 다양한 작업을 수행할 때 사용하는 작은 소프트웨어 조각입니다. API는 유연하고 독특하며, 개발 과정에서 필요에 따라 즉석에서 만들어지기도 합니다.

API는 유연하지만, 그 기능에 비해 과도한 권한이 부여된 경우가 많습니다. 개발자들은 프로그램이 개발되고 변경되는 과정에서도 계속 작동할 수 있도록 API에 많은 권한을 주는 경향이 있습니다. 하지만 이는 공격자가 API를 탈취할 경우, 단순히 특정 데이터베이스의 일부에 접근하는 권한을 넘어 네트워크 전체에 대한 관리자급 권한까지 얻을 수 있음을 의미합니다.

여러 보안 연구 기관이 오늘날 자격 증명 탈취 공격의 대다수가 API와 같은 소프트웨어를 대상으로 한다고 밝히는 것은 놀라운 일이 아닙니다. 아카마이(Akamai)는 그 비중을 전체의 75%로 추산하며, 가트너(Gartner) 역시 API 관련 취약점이 가장 빈번한 공격 벡터가 되었다고 지적합니다. 가장 최근의 솔트 랩스(Salt Labs) 보고서에 따르면 API를 향한 공격은 작년 대비 약 700% 증가했습니다.

소프트웨어를 위한 조직도 만들기

조직이 자격 증명 탈취 위협에 대응하는 방법 중 하나는 네트워크 내에서 최소 권한 원칙이나 제로 트러스트를 적용하는 것입니다. 이는 사용자가 업무를 수행하는 데 필요한 최소한의 권한만 갖도록 제한합니다. 이러한 접근 권한은 시간이나 위치와 같은 요소에 의해 더욱 엄격하게 제한되기도 합니다. 이렇게 하면 자격 증명 탈취 공격이 성공하더라도 공격자는 제한된 시간 동안 제한된 기능만 수행할 수 있어 큰 피해를 줄 수 없습니다.

최소 권한 원칙은 훌륭한 방어 수단이지만, 보통 인간 사용자에게만 적용됩니다. 우리는 API 또한 높은 권한을 가지고 있으며, 인간보다 훨씬 덜 규제된다는 사실을 잊곤 합니다. 이것이 바로 사이버 공격 패턴을 추적하는 OWASP(Open Web Application Security Project)가 손상된 접근 제어를 현재 가장 위험한 보안 위협으로 꼽는 이유 중 하나입니다.

이 중대한 문제의 해결책이 소프트웨어에 최소 권한 원칙을 적용하는 것이라고 말하기는 쉽지만, 실제로 구현하기는 훨씬 어렵습니다. 우선 개발자들에게 위험성을 알리는 것이 중요합니다. 앞으로는 API와 다른 소프트웨어를 컴퓨터 네트워크 내의 조직도 일부로 공식적으로 배치하거나 최소한 그렇게 구상해야 합니다. 예를 들어, API가 예약 애플리케이션의 일부로서 실시간 항공 데이터를 가져오는 역할을 한다면, 급여나 재무 시스템에 연결될 이유는 전혀 없습니다. 소프트웨어 조직도상에서 그러한 시스템들을 연결하는 직접적인 선은 없어야 합니다.

조직 내에서 운영되는 수천, 수백만 개의 API를 모두 보여주는 조직도를 개발자가 직접 만드는 것은 현실적이지 않을 수 있습니다. 하지만 API가 가진 위험을 인지하고 업무에 필요한 권한만 제한적으로 부여하는 것만으로도 오늘날 만연한 자격 증명 탈취 공격을 막는 데 큰 도움이 될 것입니다. 인식에서 시작하여 API와 소프트웨어를 인간 사용자만큼 엄격하게 관리하는 것이 중요합니다.
‍

개발 팀의 역량을 강화하고 싶으신가요? 당사의 애자일 학습 플랫폼과 개발자 중심 보안 도구로 API 보안 문제를 해결해 보세요.