조직 계층 구조에서 소프트웨어 재고하기

이 문서의 버전은 어두운 읽기에나타났다. 여기에 업데이트되고 신디케이트되었습니다.

‍

직장인이라면 누구나 한 번쯤은 조직에서 누가 누구에게 보고하는지를 정의하는 운영 보고 또는 계층 구조 도표를 본 적이 있을 것입니다. 조직도라고도 불리는 이 도표는 조직 내에서 누가 누구에게 보고하고 상사가 누구인지 알 수 있는 유용한 도구입니다. 예를 들어, 일반적인 조직도에서 코딩 그룹 책임자는 제품 개발 이사에게 보고하고, 이 이사는 다시 혁신 담당 부사장에게 보고합니다. 그런 다음 회사 구조의 위아래로 권한이 계속 이어집니다. 이러한 조직도를 보면서 어딘가에 자리 잡고 있는 자신의 작은 블록을 찾아본 적이 있는 사람이 있을까요?

인간이 위계와 구조에 매료되는 것은 당연한 일입니다. 역사적으로 매우 위험한 세상에 맞닥뜨렸던 고대에도 인류가 오랫동안 한 종으로서 살아남을 수 있었던 원동력이 바로 이 위계질서였으니까요. 인간은 가장 강하거나 가장 빠른 동물은 아니었지만, 가족, 부족 또는 집단의 생존과 번영을 위해 모두가 자신의 위치와 책임을 알고 팀으로 협력하여 잘 일했습니다. 현대의 조직도는 사실 그 시대와 그 고대의 성공의 연장선상에 있습니다.

하지만 비즈니스 규모나 기타 요인에 관계없이 거의 모든 조직도에는 한 가지 공통점이 있습니다. 대부분의 경우 조직도의 모든 구성 요소는 인간 또는 인간 그룹을 나타냅니다. 아직은 기계가 인간을 감독할 수 있는 단계가 아니므로 현재로서는 조직도는 전적으로 인간의 몫입니다. 하지만 소프트웨어에도 조직 계층 구조가 필요할까요?

물론 회사 조직도에 소프트웨어를 추가하자고 제안하는 것은 아닙니다. 상사를 위한 앱을 갖고 싶어하는 사람은 아무도 없습니다. 어떻게 상사에게 급여를 올려달라고 요청할 수 있겠습니까? 하지만 오늘날 우리의 애플리케이션과 프로그램이 직면하고 있는 위협 환경은 오래 전 인류의 고대 조상들이 직면했던 위험한 환경과 다르지 않습니다. 엄격한 계층 구조 내에서 앱과 소프트웨어의 책임을 정의하고 최소한의 권한으로 이러한 정책을 시행함으로써 앱과 소프트웨어가 엄청나게 거친 위협 환경에서도 생존하고 번창할 수 있도록 할 수 있습니다.

앱과 소프트웨어에 대한 공격이 사상 최고치를 기록했습니다.

소프트웨어에 대한 더 나은 조직 계층 구조를 만들어야 할 필요성을 이해하려면 먼저 위협 환경을 이해하는 것이 중요합니다. 오늘날의 공격자들과 이들을 위해 작동하는 봇 및 자동화 기반 소프트웨어는 공격에 악용할 방어 체계의 허점을 끊임없이 탐색하고 있습니다. 피싱 및 기타 인간을 대상으로 한 공격은 여전히 계속되고 있지만, 가장 숙련된 해커들은 대부분의 노력을 소프트웨어 공격으로 전환하고 있습니다.

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

API는 확실히 유연하지만, 그 기능에 비해 권한이 과도하게 부여되는 경우도 많습니다. 예를 들어, 개발자는 자신이 관리하는 프로그램이 계속 발전하고 변경되는 동안에도 계속 작동할 수 있도록 많은 권한을 부여하는 경향이 있습니다. 하지만 공격자가 이러한 권한을 침해하면 특정 데이터베이스의 한 부분에만 액세스할 수 있는 권한이 아니라 훨씬 더 많은 권한을 얻게 됩니다. 심지어 전체 네트워크에 대한 관리자 권한에 가까운 권한을 확보할 수도 있습니다.

여러 보안 연구 기관에서 오늘날 인증정보 탈취 공격의 압도적인 다수가 API와 같은 소프트웨어를 대상으로 이루어지고 있다고 말하는 것은 놀라운 일이 아닙니다. Akamai는 이 수치가 전체의 75%에 달한다고 밝혔으며, Gartner 역시 API와 관련된 취약점이 가장 빈번한 공격 벡터가 되었다고 말합니다. 그리고 가장 최근의 Salt Labs 보고서에 따르면 API에 대한 공격이 작년에 비해 700% 가까이 증가한 것으로 나타났습니다.

소프트웨어용 조직도 만들기

조직이 자격 증명 도용 위협에 대응하는 방법 중 하나는 네트워크 내에서 최소 권한 또는 제로 트러스트를 적용하는 것입니다. 이렇게 하면 사용자는 업무나 작업을 수행하는 데 필요한 최소한의 권한만 부여받도록 제한됩니다. 이러한 액세스는 시간 및 위치와 같은 요인에 의해 추가로 제한되는 경우가 많습니다. 이렇게 하면 인증정보 탈취 공격이 성공하더라도 짧은 시간 동안 제한된 기능만 수행할 수 있는 권한을 갖게 되므로 공격자에게는 큰 이득이 되지 않습니다.

최소 권한은 좋은 방어 수단이지만, 일반적으로 사람 사용자에게만 적용됩니다. 우리는 API도 높은 권한을 가지고 있으며 규제가 거의 없다는 사실을 간과하는 경향이 있습니다. 이것이 바로 사이버 공격 패턴을 추적하는 오픈 웹 애플리케이션 보안 프로젝트(OWASP)에 따르면 취약한 접근 제어가 공공의 적 1위로 꼽히는 이유 중 하나입니다. 

이 중요한 문제에 대한 해결책은 단순히 소프트웨어에 최소 권한을 적용하는 것이라고 말하기는 쉽습니다. 하지만 구현하기는 훨씬 더 어렵습니다. 먼저 개발자에게 위험성을 인식시켜야 합니다. 그리고 앞으로는 API와 기타 소프트웨어를 공식적으로 배치하거나 적어도 해당 소프트웨어가 상주할 컴퓨터 네트워크 내의 조직도의 일부로 배치하는 것을 구상해야 합니다. 예를 들어, API가 예약 애플리케이션의 일부로 실시간 항공편 데이터를 가져와야 한다면 급여 또는 재무 시스템과도 연결할 수 있어야 할 이유가 없습니다. 소프트웨어 조직도에는 이러한 시스템을 직접 연결하거나 점선으로 연결하지 않을 것입니다.

개발자가 실제로 조직에서 작동하는 수천, 수백만 개의 API를 보여주는 조직도를 만드는 것은 비현실적일 수 있습니다. 하지만 API의 위험성을 인식하고 업무 수행에 필요한 권한으로만 제한하는 것만으로도 오늘날 만연한 인증정보 탈취 공격을 막는 데 큰 도움이 될 것입니다. 이는 인식에서 시작하여 API와 소프트웨어를 인간 사용자와 동일하게 면밀하게 취급하는 것으로 끝납니다.
‍

개발팀의 수준을 높이고 싶으신가요? API 보안 문제 등을 탐색하는 애자일 learning platform 개발자 우선 보안 도구로 API 보안 문제 등을 해결하세요.