지난달에 글을 썼어요 기사 로우 코드/노 코드 플랫폼이 자격 증명 공유를 서비스로 제공하는 방식, 이를 수행하는 이유, 그리고 이것이 어떻게 보이는지에 대해 공격자의 관점. 이 기사에서는 이러한 타협의 의미와 그것이 오늘날 기업에 어떤 영향을 미치는지에 초점을 맞추겠습니다.
기업 자격 증명을 다른 사람과 공유하는 것이 나쁜 습관인 이유는 다음과 같습니다. 일회성 사용자 행동 분석을 위해 프로덕션 로그를 쿼리하기 위해 내 자격 증명을 동료에게 전달하고 싶다고 가정해 보겠습니다. 일반적인 기업에서는 누군가에게 새로운 데이터 소스를 쿼리할 수 있는 권한을 부여한다는 것은 특히 프로덕션 데이터나 중요한 데이터의 경우 액세스 검토 프로세스가 길어질 수 있음을 의미합니다. 내 동료는 쉽게 좌절감을 느낄 수 있습니다. "내가 원했던 것은 이 작은 일회성 쿼리뿐이었고, 벌써 한 달을 기다려왔습니다!" 그들은 말할 수 있었습니다. 그냥 쿼리를 실행할 수도 있지만 일상적인 작업으로 너무 바빠서 일회성 쿼리가 복잡해지는 경향이 있습니다.
한 가지 빠른 해결책이 남았습니다. 내 사용자 이름/비밀번호를 동료와 공유하면 됩니다. MFA 챌린지를 받으면 기꺼이 승인하겠습니다. 쿼리를 실행하는 데 시간을 소비할 필요가 없으며 동료의 차단이 해제됩니다. 모두가 승리합니다! 오른쪽?
글쎄요, 당신의 분석은 옳을 것입니다. 그러나 당신은 더 큰 그림을 놓치고 있습니다. 동료가 사용자 행동 분석을 수행하는 것이 기업에 중요하지만, 기업이 다양한 개인 정보 보호 및 보안 표준을 계속 준수하고 보안에 대한 회사의 약속을 유지함으로써 고객 신뢰를 유지하는 것도 마찬가지로 중요합니다. .
높은 수준의 기업 목표가 설득력이 없다면 IT 또는 보안의 중앙 관리 팀을 고려해 보십시오. 이러한 팀은 각 사용자가 고유한 ID를 가지고 있다는 사실을 기반으로 운영 및 보안 전략을 수립합니다. IT 팀은 각 사용자가 하나의 기업 IP 또는 기업 노트북에서 동시에 로그인한다고 가정하는 네트워킹 및 액세스 정책을 설정하고 있습니다. 보안팀은 사용자 ID를 기반으로 이벤트의 상관 관계를 파악하고 있습니다. 재무팀은 사용자 및 개인 클라우드 환경별로 비용 보고서를 집계할 수 있습니다. 자격 증명 공유는 무엇보다도 이러한 모든 가정을 약화시킵니다. 이는 온라인 신원의 기본 의미를 제거합니다.
실제 사례
로우코드/노코드의 세계로 돌아가 실제 시나리오를 살펴보겠습니다. 대기업의 고객 관리 팀에서 영감을 받은 직원인 Jane은 조직 전체의 직원이 고객 사례에 참여할 때 일반적으로 지원 사례 내역 및 최신 구매와 같은 고객에 대한 주요 정보가 누락된다는 것을 깨달았습니다. 사례가 문제를 해결할 수 있는 적절한 직원에게 전달되는 동안 문제를 계속해서 설명해야 하기 때문에 고객 경험이 저하됩니다.
이를 개선하기 위해 Jane은 회사 직원이 고객 지원 사례 해결을 담당하는 팀에 속해 있을 때 고객에 대한 주요 정보를 볼 수 있는 앱을 만들었습니다. 먼저, Jane이 예산을 요청하거나 IT 리소스 할당을 기다리지 않고 스스로 요구 사항을 식별하고 해결할 수 있게 해주는 로우 코드/노 코드의 힘을 인정하는 시간을 가져보겠습니다.
애플리케이션을 구축하는 동안 Jane은 여러 문제를 해결해야 했는데 가장 큰 문제는 권한이었습니다. 조직 전체의 직원은 필요한 정보를 얻기 위해 고객 데이터베이스를 쿼리할 수 있는 직접적인 액세스 권한이 없습니다. 그렇다면 Jane은 이 애플리케이션을 구축할 필요가 없을 것입니다. 이 문제를 극복하기 위해 Jane은 데이터베이스에 로그인하고 인증된 세션을 애플리케이션에 직접 포함시켰습니다. 애플리케이션이 한 사용자로부터 요청을 받으면 Jane의 ID를 사용하여 해당 쿼리를 실행한 다음 결과를 사용자에게 반환합니다. 이 자격 증명 내장 기능은 지난 달에 조사한 대로는 로우코드/노코드 플랫폼의 핵심 기능입니다. Jane은 모든 사용자가 자신에게 할당된 고객 사례에만 액세스할 수 있도록 애플리케이션에 RBAC(역할 기반 액세스 제어)를 설정했습니다.
이 애플리케이션은 중요한 비즈니스 문제를 해결하여 기업 전체에서 빠르게 사용자 채택을 얻었습니다. 사람들은 대화에 적합한 맥락을 가짐으로써 고객에게 더 나은 서비스를 제공할 수 있다는 사실에 기뻐했습니다. 고객도 기뻐했습니다. Jane이 애플리케이션을 만든 지 한 달 만에 조직 전체의 수백 명의 사용자가 이미 이 애플리케이션을 사용했으며 고객 만족도도 높아졌습니다.
한편 SOC에서는 프로덕션 고객 데이터베이스 주변의 비정상적인 활동을 보여주는 심각도가 높은 경고가 트리거되어 숙련된 보안 분석가인 Amy에게 할당되었습니다. Amy의 초기 조사에 따르면 내부 사용자가 조직 전체의 여러 IP 주소에서 여러 고객에 대한 정보를 쿼리하면서 전체 데이터베이스를 긁어내려고 시도하고 있는 것으로 나타났습니다. 쿼리 패턴은 매우 복잡했습니다. 데이터베이스를 스크래핑할 때 볼 수 있는 단순한 열거 패턴 대신 동일한 고객의 데이터가 여러 번 쿼리되었으며 때로는 다른 IP 주소와 다른 날짜를 통해 쿼리되었습니다. 보안 모니터링 시스템을 혼란시키려는 공격자가 아닐까요?
빠른 조사 끝에 Amy는 중요한 정보를 발견했습니다. 모든 IP 주소와 날짜에 대한 모든 쿼리는 고객 관리 팀의 Jane이라는 이름의 단일 사용자 ID를 사용하고 있었습니다.
Amy는 Jane에게 연락하여 무슨 일이 일어나고 있는지 묻습니다. 처음에 Jane은 몰랐습니다. 그녀의 자격 증명이 도난당했나요? 그녀가 잘못된 링크를 클릭했거나 잘못된 수신 이메일을 신뢰했습니까? 그러나 Jane이 Amy에게 자신이 최근에 구축한 애플리케이션에 대해 말했을 때 두 사람 모두 연결이 있을 수 있다는 것을 깨달았습니다. SOC 분석가인 Amy는 로우 코드/노코드에 익숙하지 않았기 때문에 AppSec 팀에 연락했습니다. Jane의 도움으로 팀은 Jane의 애플리케이션에 Jane의 자격 증명이 포함되어 있다는 사실을 알아냈습니다. 데이터베이스의 관점에서 보면 애플리케이션은 없었습니다. 단지 Jane만이 수많은 쿼리를 실행하고 있었습니다.
Jane, Amy 및 AppSec 팀은 솔루션을 찾을 때까지 애플리케이션을 종료하기로 결정했습니다. 조직 전체의 애플리케이션 사용자는 애플리케이션에 의존하게 되었기 때문에 좌절감을 느꼈고 고객도 이를 느꼈습니다.
Amy가 문제를 종결하고 조사 결과를 문서화하는 동안 고객 관리 담당 부사장은 고객 만족도가 떨어지는 것을 보고 만족하지 않았기 때문에 Jane에게 영구적인 솔루션을 찾아보라고 요청했습니다. 플랫폼 문서와 조직의 Center of Excellence 팀의 도움으로 Jane은 애플리케이션에서 내장된 ID를 제거하고, 각 사용자의 ID를 사용하여 데이터베이스를 쿼리하도록 앱을 변경했으며, 사용자가 자신과 관련된 고객 사례에 대해서만 권한을 얻도록 했습니다. . 새롭고 향상된 버전에서 애플리케이션은 각 사용자의 ID를 사용하여 고객 데이터베이스를 쿼리했습니다. Jane과 애플리케이션 사용자는 애플리케이션이 다시 온라인 상태가 되어 기뻐했고, Amy와 AppSec 팀은 Jane의 신원이 더 이상 공유되지 않는다는 사실에 기뻐했으며, 기업에서는 고객 만족도가 다시 상승하기 시작했습니다. 모든게 괜찮 았어.
XNUMX주 후 SOC는 생산 고객 데이터베이스에 대한 비정상적인 액세스에 대한 또 다른 경고를 받았습니다. 이는 동일한 데이터베이스에 대한 이전 경고와 의심스러울 정도로 유사해 보였습니다. 이번에도 조직 전체의 IP 주소는 단일 사용자의 ID를 사용하여 데이터베이스를 쿼리했습니다. 이번에도 그 사용자는 Jane이었습니다. 그러나 이번에 보안팀과 Jane은 앱이 사용자의 신원을 사용한다는 것을 알고 있었습니다. 무슨 일이야?
조사 결과 원래 앱에는 다음이 포함된 것으로 나타났습니다. 암시적으로 공유됨 앱 사용자와의 Jane의 인증된 데이터베이스 세션입니다. 사용자와 앱을 공유함으로써 해당 사용자는 다음에 직접 액세스할 수 있게 되었습니다. 연결, 로우 코드/노 코드 플랫폼에서 제공하는 인증된 데이터베이스 세션에 대한 래퍼입니다. 해당 연결을 사용하면 사용자는 인증된 세션을 직접 활용할 수 있으며 더 이상 앱을 거칠 필요가 없습니다. 여러 사용자가 이 사실을 발견하고 이것이 의도된 동작이라고 생각하여 Jane의 인증된 데이터베이스 세션을 사용하여 쿼리를 실행한 것으로 나타났습니다. 연결을 사용하면 자신에게 할당된 고객 사례뿐만 아니라 데이터베이스에 대한 전체 액세스 권한을 직접 부여할 수 있기 때문에 그들은 이 솔루션을 좋아했습니다.
연결이 삭제되어 사건은 종료되었습니다. SOC 분석가는 Jane의 연결을 사용한 사용자에게 연락하여 그들이 저장한 고객 데이터를 모두 폐기했는지 확인했습니다.
로우 코드/노 코드 보안 문제 해결
위의 이야기는 다국적 B2C 회사의 실제 시나리오입니다. 개인정보 보호를 위해 일부 내용이 생략되거나 조정되었습니다. 우리는 선의의 직원이 자신도 모르게 자신의 신원을 다른 사용자와 공유하여 IT, 보안 및 비즈니스 전반에 걸쳐 광범위한 문제를 일으킬 수 있는 방법을 살펴보았습니다. 지난달에 살펴본 것처럼 자격 증명 공유는 로우 코드/노 코드의 핵심 기능입니다. 이는 예외가 아닌 표준입니다.
As 의식적이든 아니든 기업에서는 로우 코드/노 코드가 계속해서 만개하고 있습니다., 보안 및 IT 팀이 비즈니스 개발 대화에 참여하는 것이 중요합니다. 로우코드/노코드 앱은 고유한 보안 과제 세트, 그리고 그들의 다작 특성은 이러한 과제가 그 어느 때보다 더 빠르게 심각해진다는 것을 의미합니다.
