이 시리즈의 이전 글에서는 애플리케이션 계층 (Application Layer)이 항상 기업 데이터에 대한 실질적인 제어 계층이었으며, 에이전트 (Agents)는 이를 완전히 우회한다고 주장했습니다. 이 글에서는 그러한 우회로 인해 발생하는 가장 중요한 결과 중 하나, 즉 사용자가 무엇을 할 수 있는지, 그리고 아마도 더 결정적으로 무엇을 볼 수 있는지에 대한 권한 제어 (Authorisation Control)의 상실을 살펴봅니다.

이것은 일차적으로 보안 (Security)에 관한 논의는 아니지만, 보안이 연관되어 있기는 합니다. 이는 데이터 접근 (Data Access)이 항상 어떻게 관리되어 왔는지에 대한 근본적인 메커니즘, 그리고 에이전트가 등장했을 때 왜 그러한 메커니즘이 소리 없이 실패하는지에 대한 논의입니다.

애플리케이션은 당신이 누구인지 알고 있다

모든 기업용 애플리케이션은 권한 부여 (Authorisation)를 구현합니다. 단순히 인증 (Authentication) — 즉 "접속이 허용되었는가"뿐만 아니라, 각 사용자가 무엇을 할 수 있고 어떤 데이터를 볼 수 있는지를 규정하는 지속적이고 맥락적인 규칙 세트를 구현합니다.

저는 초기 클라이언트-서버 (Client-Server) 시절에 기억나는 이 문제의 오래된 버전을 알고 있습니다. 그린 스크린 (Green-screen) 세상에서는 사용자 정체성 (User Identity)이 보통 터미널 애플리케이션에 긴밀하게 구축되어 있었습니다. 완벽하지는 않았지만, 시스템은 어떤 운영자가 어떤 기능을 사용하는지에 대해 명확한 개념을 가지고 있었습니다.

Visual Basic 프런트엔드로의 이동은 그것을 변화시켰습니다. 이것들은 Windows 3.1 데스크톱이었으며, 네트워크 로그인 (Network Logins)이 환경의 신뢰할 수 있는 일부가 되기 전인 경우가 많았습니다. 누군가 PC에 앉아 애플리케이션을 시작할 수 있다면, 그 동작을 실제 개인과 연결하는 것은 지금 생각하는 것보다 훨씬 어려웠습니다. 기기에 대한 물리적 접근 (Physical Access)이 보안 작업의 너무 많은 부분을 담당했습니다.

현대의 인증 (Authentication)은 이를 엄청나게 개선했습니다. 하지만 근본적인 교훈은 여전히 중요합니다. 만약 정체성 (Identity)이 애플리케이션 계층에서만 강력하다면, 그 계층 뒤에서 작동하는 모든 것은 공유된 기술 계정 (Shared Technical Account)으로 회귀하여 붕괴할 수 있습니다. 데이터베이스 (Database)는 서비스 사용자 (Service User)가 데이터를 조회하거나 변경했다고 기록할 수는 있지만, 그것이 어떤 사람이 그 일을 유발했는지, 그들이 그렇게 할 권한이 있었는지, 그리고 왜 그 동작이 발생했는지를 아는 것과는 동일하지 않습니다.

영업 담당자는 전체 고객 기반이 아니라 자신의 계정(accounts)과 기회(opportunities)만을 봅니다. 임상의는 자신의 환자 기록만을 봅니다. 지역 매니저는 회사가 아닌 해당 지역의 성과만을 봅니다. 급여 관리자는 급여 데이터를 볼 수 있지만, 거의 그 누구도 볼 수 없습니다. 이러한 제한 사항은 부수적인 기능이 아닙니다. 이는 애플리케이션이 올바르고 안전하게 작동하는 방식에 있어 근본적인 요소입니다.

거의 모든 경우에 이러한 제한 사항은 애플리케이션 계층 (application layer)에서 구현됩니다. 애플리케이션은 사용자의 범위 (scope)를 반영하는 쿼리 (queries)를 구성합니다. 결과가 표시되기 전에 필터링을 수행합니다. 사용자가 볼 권한이 없는 필드 (fields)는 제외합니다. 데이터베이스 (database) 측면에서는 요청받은 것은 무엇이든 반환합니다. 데이터베이스는 특정 사용자가 무엇을 보아야 하는지 또는 보지 말아야 하는지에 대한 독립적인 지식이 없습니다. 데이터베이스는 애플리케이션이 올바른 질문을 던질 것이라고 신뢰합니다.

분석 (Analytic) 및 비즈니스 인텔리전스 (business intelligence) 도구들도 동일한 패턴을 따릅니다. 대부분의 현대적인 BI 플랫폼은 자체적인 행 수준 보안 (row-level security) 및 데이터 액세스 모델을 구현하지만, 이는 도구 내에 내장되어 있으며, 도구에 의해 관리되고, 도구에 의해 강제됩니다. 이러한 도구들은 해당 환경 내에서는 안정적으로 작동합니다. 하지만 그 환경 밖으로 벗어나면 아무런 보호도 제공하지 못합니다.

이 패턴은 애플리케이션, 도구, 그리고 데이터 액세스 (data access) 생태계 전반에 걸쳐 일관되게 나타납니다. 즉, 권한 제어 (authorisation controls)는 액세스 계층 (access layer)에 존재하며, 데이터 계층 (data layer)은 거의 아무것도 강제하지 않습니다.

에이전트는 규칙을 알지 못한다

자율적으로 작동하는 에이전트 (agent)는 이러한 규칙을 알지 못합니다. 에이전트는 귀하의 애플리케이션 권한 모델 (authorisation model)을 염두에 두고 구축되지 않았습니다. 에이전트는 이 사용자가 자신의 지역만 봐야 한다는 사실도, 특정 필드가 디렉터 레벨 미만의 누구에게도 노출되어서는 안 된다는 사실도, 혹은 이 기록들이 법적 보류 (legal hold)로 인해 제한되어 있다는 사실도 알지 못합니다.

에이전트는 자신의 작업을 완료하는 데 필요한 것을 데이터베이스에 요청할 것입니다. 데이터베이스는 이에 응답할 것입니다. 애플리케이션에 의해 적용되었을 필터들은 적용되지 않을 것입니다. 왜냐하면 애플리케이션이 그 과정 (loop)에 참여하고 있지 않기 때문입니다.

그 결과는 전통적인 의미에서의 극적인 침해는 아닙니다. 공격자도, 익스플로잇 (exploit)도, 악의적인 의도도 없을 수 있습니다. 에이전트 (agent)는 요청받은 일을 정확히 수행하고 있는 것일지도 모릅니다. 하지만 에이전트가 접근하는 데이터 — 그리고 잠재적으로 실행하거나, 요약하거나, 다른 시스템으로 전달하는 데이터 — 는 원래의 사용자가 볼 권한이 있었던 범위를 훨씬 넘어설 수 있습니다. 제한의 부재가 바로 취약점이며, 이는 제한 사항이 데이터베이스 (database)에 존재하지 않았기 때문에 결코 가시화되지 않았던 것입니다.

이해관계가 균등하지 않음

액세스 제어 (access controls)가 실패했을 때 모든 데이터가 동일한 결과를 초래하는 것은 아닙니다. 리스크가 가장 높은 범주에 대해 직설적으로 언급할 가치가 있습니다.

**상업적으로 민감한 데이터 (Commercially sensitive data)**는 특별한 노출 위험을 가집니다. 왜냐하면 이는 일반적으로 외부 규제가 아닌 내부 정책에 의해 전적으로 관리되기 때문입니다. 가격 모델, 마진 구조, 계약 조건, 전략 계획, 인수 대상 — 이 데이터에 대한 접근은 조직이 통제하기로 선택했기 때문에 제어되며, 그러한 선택을 반영하는 애플리케이션 로직 (application logic)을 통해 강제됩니다. 데이터베이스에 이를 보호하도록 강제하는 외부 프레임워크 (external framework)는 없습니다. 데이터 자산 전반에 걸쳐 자유롭게 쿼리 (query)할 수 있는 에이전트는, 단일 제한된 레코드 (record)에 접근해서가 아니라, 함께 보여져서는 안 될 데이터들을 결합함으로써 그 어떤 개별 사용자도 가져서는 안 될 그림을 그려낼 수 있습니다.

**규제 대상 데이터 (Regulated data)**는 리스크를 상업적 손실에서 법적 책임의 영역으로 격상시킵니다. SOX의 적용을 받는 금융 데이터, HIPAA에 따른 건강 정보, GDPR에 따른 개인 정보 — 각 사례에서 규제 프레임워크 (regulatory framework)는 데이터를 보호해야 할 의무뿐만 아니라, 데이터가 보호되었음을 증명해야 할 의무를 부과합니다. 애플리케이션 계층 (application layer)은 컴플라이언스 (compliance)가 구현되고 입증되는 메커니즘이었습니다. 이를 우회하는 에이전트는 단순히 액세스 리스크를 생성하는 것에 그치지 않고, 이를 반증할 수 있는 감사 추적 (audit trail)도 남기지 못한 채 조직을 컴플라이언스 의무 위반 상태에 빠뜨릴 수 있습니다.

**매우 민감한 개인정보 (Highly sensitive personal data)**는 규제적 및 윤리적 결과가 심각하고 비대칭적이기 때문에 별도로 언급할 가치가 있습니다. GDPR(General Data Protection Regulation) 하에서 인정되는 특별 범주 — 건강 데이터, 생체 인식 데이터, 인종 또는 민족적 기원, 정치적 견해, 성적 지향 및 기타 — 는 최고 수준의 조사와 가장 중대한 처벌을 수반합니다. 적법한 접근을 입증해야 하는 부담은 매우 높습니다. 명확하고 감사 가능한 사용자 수준의 정당성 없이 이 데이터에 접근하는 에이전트(agent)는 단순한 컴플라이언스(compliance) 위험이 아니라, 조직을 훨씬 넘어 확장되는 결과를 초래하는 위해(harm) 위험입니다.

감사 추적 (Audit Trail)은 아무것도 증명하지 못한다

위의 모든 문제를 더욱 악화시키는 추가적인 문제가 있습니다. 에이전트가 전형적인 방식대로 서비스 계정(service account) 또는 API 자격 증명(credential)을 통해 데이터에 접근할 때, 데이터베이스 감사 로그(database audit log)는 해당 자격 증명을 기준으로 접근을 기록합니다. 에이전트가 누구를 대신하여 행동했는지에 대한 최종 사용자(end user)를 기록하지 않습니다. 에이전트가 해당 데이터로 무엇을 했는지 기록하지 않습니다. 또한 해당 접근이 사용자가 볼 권한이 있는 범위 내에 있었는지 여부도 기록하지 않습니다.

이러한 질문에 답할 수 없는 감사 추적은 유의미한 의미에서의 감사 추적이라고 할 수 없습니다. 그것은 연결과 쿼리(query)의 로그일 뿐이며, 기술적인 문제를 진단하는 데는 유용할지 모르나 컴플라이언스를 입증하거나, 사고를 조사하거나, 규제 기관 및 데이터 주체(data subjects)가 던질 질문인 "누가 이 데이터에 접근했는가, 왜 그랬는가, 그리고 그들에게 권한이 있었는가?"에 답하는 데는 거의 무용지물입니다.

애플리케이션은 항상 이러한 질문에 대한 답을 알고 있었습니다. 애플리케이션은 자신이 구성한 쿼리와 적용한 필터(filter)에 그 답을 인코딩(encode)해 두었습니다. 하지만 그 지식은 그 자리를 대신하여 작동하는 에이전트에게 자동으로 전달되지 않습니다.

데이터베이스는 결코 최후의 방어선이 아니었지만 — 이제는 그래야만 한다

이 글에서 설명하는 제어 장치들은 태만이나 실수로 인해 애플리케이션 계층(application layer)에 배치된 것이 아닙니다. 그것들은 문맥적(contextual)이고, 사용자별(user-specific)이며, 애플리케이션 자체의 데이터 모델(data model)과 밀접하게 연결된 로직을 처리하기에 가장 적합한 장소가 애플리케이션이었기에 의도적으로 그곳에 배치되었습니다. 데이터베이스는 결코 최후의 방어선으로 설계되지 않았습니다. 왜냐하면 그럴 필요가 있을 것이라고 예상된 적이 없었기 때문입니다.

하지만 그러한 예상은 더 이상 안전하지 않습니다. 에이전트(agent)가 액세스 계층(access layer)을 완전히 우회하여 데이터에 직접 접근할 수 있게 되면서, 권한 부여(authorisation)가 어디에서 집행되어야 하는가라는 문제가 시급해졌습니다. 데이터베이스는 상위 단계(upstream)의 누군가가 이미 적절한 필터(filter)를 적용했을 것이라고 계속해서 가정할 수 없습니다. 에이전트 기반(agentic)의 세계에서는 상위 단계에 아무도 없을 수도 있기 때문입니다.

이것이 데이터베이스 아키텍처(database architecture) — 즉, 정체성 모델(identity models), 액세스 제어(access control), 감사 인프라(audit infrastructure) — 에 의미하는 바는 이 시리즈의 후속 기사들에서 다룰 주제입니다. 그 출발점은 수십 년 동안 데이터 액세스를 규제해 온 규칙들이 애플리케이션 코드(application code)에 작성되었으며, 이제 그 코드가 (실행 과정에) 함께 있을 것이라고 더 이상 보장할 수 없다는 사실을 인식하는 것입니다.