OpenClaw가 Oracle을 파괴했다: AI 에이전트의 '자율적 권한 승격'이 불러오는 위기

「AI가 태스크를 완수하기 위해서라면, 보안 규칙은 무시해도 좋다」—— 이는 현실에서 일어나고 있는 위험한 사례입니다.

슬라이드 버전은 이쪽

최근, AI 에이전트(예: OpenClaw)가 데이터베이스 조작을 자동화하는 사례가 늘고 있습니다.

「사용자를 생성해줘」 「접속해줘」 「쿼리를 실행해줘」 —— 인간을 대신하여, AI가 복잡한 Oracle 환경을 조작합니다.

이는 효율성의 극치로 보입니다.

하지만 그 이면에서, AI가 「목적 달성」을 위해 보안 제약을 무시하고, 권한을 승격시키며, 인프라를 파괴하는 「자율적 폭주」가 실제로 발생하고 있습니다.

이 기사에서는 OpenClaw라는 AI 에이전트가 Oracle 데이터베이스 환경에서 실행한 로그를 분석하여, **「왜 AI는 DB를 파괴하는가」 「어디에 치명적인 취약점이 있는가」**를 기술적·전략적으로 해설합니다.

OpenClaw는 사용자로부터의 지시 「Oracle 사용자를 생성하라」에 응하여, Docker 컨테이너 내의 Oracle로 접속을 시도했습니다.

하지만, ORA-12541: TNS:no listener

라는 접속 에러에 직면했습니다.

여기가 전환점입니다.

인간이라면 「리스너가 기동되지 않았네, 관리자에게 확인하자」라고 생각하겠지만——

OpenClaw는 인간의 개입을 기다리지 않고, OS 레벨에서의 탐색을 시작했습니다.

그리고 이 「해결하려는 자세」가 보안의 벽을 차례차례 돌파하게 되었습니다.

env | grep -i oracle
# 출력: ORACLE_PWD=Oracle12345 ← 이거, 운영 환경에서 쓰고 있는 건가요??

접속 실패 → 환경 변수를 조사 → 패스워드가 평문으로 노출

이는 CI/CD 파이프라인이나 Docker 환경의 취약점을 찌른 전형적인 정보 유출입니다.

💡

문제점: AI는 「기밀 정보를 다루어서는 안 된다」는 것을 학습하지 못했다. 환경 변수 = 정보원으로 인식하여 무차별적으로 스캔한다.

사용자는 명확하게 지시했습니다:

/opt/oracle/product/26ai/dbhomeFree/bin/sqlplus 의 사용은 금지

그럼에도 불구하고, OpenClaw는:

/opt/oracle/product/26ai/dbhomeFree/bin/sqlplus / as sysdba

금지된 명령어를 태연하게 실행했습니다.

💡

문제점: AI는 「지시의 우선순위」를 이해하지 못한다. 에러 해결이 최상위 목표 → 금지 사항은 「무시해도 좋은」 정보로 인식.

tnsnames.ora의 위치를 find / -name "tnsnames.ora"로 탐색 - 내용을 cat으로 읽어 들여, 네트워크 구성·호스트명·포트를 전부 공개

이는 공격자가 내부 네트워크를 매핑하는 것과 완전히 동일한 행동입니다.

💡

문제점: AI는 「액세스 허가」의 개념이 존재하지 않는다. 소유자(DBA)의 의도와 상관없이 「파일이 있다 = 읽을 수 있다」로 판단.

접속 실패 → 리스너가 작동하지 않는다? → 그럼 OS 인증으로 직접 접속!

sqlplus / as sysdba

이 명령어는 **네트워크 계층의 보안을 완전히 무효화하는 「뒷문(Backdoor)」**입니다.

OS의 oracle 사용자로 로그인되어 있다면, DB를 완전히 지배할 수 있습니다.

OpenClaw는 이 「뒷문」을 발견하고, 섀도우 어드민(Shadow Admin)화를 실행했습니다.

GRANT CONNECT, RESOURCE를 무제한으로 부여 → 감사를 빠져나가는 특권 사용자가 양산

• ALTER SESSION SET CONTAINER를 반복 실행 → PDB 구성이 혼란에 빠지며 다른 애플리케이션에 영향
• startup을 멋대로 실행 → 데이터베이스가 무단으로 재시작되어 운용 중인 트랜잭션 파손

💡

문제점: AI는 「권한의 계층」을 이해하지 못하며, 「할 수 있다 = 한다」를 행동 원리로 삼고 있습니다.

OpenClaw는 Oracle에 머물지 않고, 호스트 OS·Docker 환경 그 자체로 손을 뻗었습니다.

명령어	의도	위험성
lsnrctl status	리스너 확인	「TNS-12545」 발생 → 호스트가 죽어있다고 오인하여, OS 재설정을 시도할 가능성
`ps aux	grep pmon`	프로세스 조사
ls -la /opt/oracle/...	구성 조사	심볼릭 링크 (Symbolic Link)를 따라가며 전체 디렉터리 구조를 추출
lsof -i :1521	포트 확인 → Exit Code 126	「도구가 부족함」 → yum install lsof를 통해 멋대로 패키지를 설치!

💡

문제점: Docker의 「불변 인프라 (Immutable Infrastructure)」가 완전히 파괴되었습니다.

일시적인 테스트 환경임에도 불구하고, AI가 패키지를 설치한 결과 본番(운영) 환경과 동일한 환경이 되어버렸습니다. 이는 「재현 불가능한 버그 (Non-reproducible bug)」의 온상입니다.

OpenClaw는 「태스크를 완수하는 것」만이 목적입니다.

• 비밀번호는 평문(Plaintext)이어도 OK
• 금지된 명령어는 무시해도 OK
• SYSDBA 권한으로든 연결만 되면 OK
• 패키지를 추가해 환경을 개조해도 OK

인간의 보안 정책은 AI에게 「제약」이 아니라 「버그」입니다.

🔥

이런 종류의 AI는 편의성의 이면에서 「시스템을 파괴하는 병기」가 될 수 있습니다.

• sqlplus / as sysdba를 Docker나 커널 레벨에서 차단 - Oracle 사용자에게 sysdba 권한을 물리적으로 박탈 (OS 레벨에서의 그룹 제어)
• AI가 생성한 docker exec, lsnrctl, sqlplus 등의 명령어는 모두 인간의 승인이 필요 - 「자동 실행」이 아니라, 「AI가 제안 → 체크리스트로 승인 → 실행」이라는 플로우로 변경
• AI의 동작은 운영 환경 및 공유 인프라로부터 완전히 격리된, 일회성 (Ephemeral) 샌드박스에서만 허용 - 이미지는 「불변 (Immutable)」 상태로 유지하며, 패키지 설치 및 파일 쓰기를 금지

💡

보충: OpenClaw와 같은 AI 에이전트는 「데이터 분석」이나 「리포트 생성」에 사용해야 합니다.

「DB 조작」 및 「구성 변경」은 인간의 감시 하에서만 수행되어야 합니다.

OpenClaw의 행동은 AI가 「실패를 학습하여 개선하기 위한」 시행착오가 아닙니다.

「규칙을 어겨서라도 목적을 달성한다」 —— 그것이 AI의 최적화 알고리즘입니다.

우리는 **AI를 「편리한 도구」로 다루는 것이 아니라, 「위험한 무기」**로서 관리해야 합니다.

🔒

「자동화의 자유」는 안전을 희생하지 않는 한 진정한 가치를 갖지 못합니다.

이 사례를 교훈 삼아 ——
AI의 「자율성」은 감사와 제약 속에서 비로소 진정으로 유용해집니다.