오라클 KISA 계정관리 6~10번: 확인 SQL과 조치 방법 정리

DB 보안 점검 · 계정관리/접근관리

오라클 KISA 6~10번: 확인 방법과 조치 방법(SQL/설정)

아래는 KISA 점검표 중 6~10번(D-06~D-10)을 대상으로, 확인 SQL(점검)과 조치 방법(권고)을 운영 적용 관점에서 정리한 내용이다. 일부 항목은 DB 내부 SQL만으로 한계가 있어 OS/네트워크/리스너 설정 확인을 함께 포함했다.

범위: D-06 ~ D-10 · 대상: Oracle DB 운영/접속 정책

적용 전 공통 체크

실무 기준으로 보면
“정책을 강하게 바꾸는 것”보다 “업무 영향 없이 단계적으로 전환하는 것”이 성공 확률이 높다.
특히 연동/배치 계정은 서비스 의존성이 있으므로, 변경 전 반드시 담당자 승인과 점검 창구를 확보한다.

• 조회 뷰: DBA_USERS, DBA_PROFILES, V$SESSION, (가능 시) UNIFIED_AUDIT_TRAIL
• 버전/옵션에 따라 일부 컬럼·뷰가 다를 수 있음(환경에서 존재 여부 확인 후 사용)

D-06 DB 사용자 계정을 개별적으로 부여하여 사용(중/2)

공유 계정은 추적성(누가/언제/무엇을)과 통제가 무너진다. 개인별 계정으로 전환하고, 연동 계정은 별도 표준(용도·권한·만료·접속구간)을 둬서 관리한다.

확인 방법(SQL)

-- 1) 사용자 계정 현황(시스템 계정 제외)
SELECT username, account_status, created, profile
FROM dba_users
WHERE oracle_maintained = 'N'
ORDER BY created DESC;

-- 2) 현재 접속 세션에서 "공유로 의심되는" 계정 패턴 확인(예: APP, ADMIN, OPER 등)
-- 실제 환경의 계정 네이밍 규칙에 맞춰 LIKE 조건을 조정
SELECT username, osuser, machine, program, COUNT(*) AS session_cnt
FROM v$session
WHERE username IS NOT NULL
  AND (UPPER(username) LIKE '%APP%' OR UPPER(username) LIKE '%ADMIN%' OR UPPER(username) LIKE '%OPER%')
GROUP BY username, osuser, machine, program
ORDER BY session_cnt DESC;

-- 3) (가능 시) Unified Auditing에서 최근 로그인 사용자 파악(환경에 따라 컬럼/옵션 차이 가능)
-- 실패 시 해당 뷰 사용 불가이므로 생략하고 OS/미들웨어 로그로 대체
SELECT dbusername, userhost, action_name, event_timestamp
FROM unified_audit_trail
WHERE action_name = 'LOGON'
  AND event_timestamp > SYSTIMESTAMP - INTERVAL '7' DAY
ORDER BY event_timestamp DESC;

* “공유 계정 여부”는 SQL만으로 100% 단정하기 어렵다.
계정명 규칙, 접속 호스트/프로그램 분포, 감사 로그(로그온/권한 사용), 운영 문서(계정-담당자 매핑)를 함께 봐야 한다.

조치 방법(권고)

-- 1) 개인 계정 발급(예시)
CREATE USER USER_JHLEE IDENTIFIED BY "강력한비밀번호_예시!2026";
ALTER USER USER_JHLEE PROFILE SECURE_PROFILE;

-- 2) 역할(Role)로 권한을 묶어서 최소 권한 부여(예시)
CREATE ROLE ROLE_REPORT_READ;
GRANT CREATE SESSION TO ROLE_REPORT_READ;
-- 필요 오브젝트 권한은 스키마 기준으로 최소 부여(예시)
-- GRANT SELECT ON APP_SCHEMA.REPORT_TABLE TO ROLE_REPORT_READ;

GRANT ROLE_REPORT_READ TO USER_JHLEE;

-- 3) 공유 계정은 단계적으로 제한
-- (a) 먼저 비밀번호 변경 + 접속 구간 제한(방화벽/프록시)
-- (b) 이후 ACCOUNT LOCK 전환
ALTER USER APP_SHARED ACCOUNT LOCK;

D-07 root 권한으로 서비스 구동 제한(중/2)

DB/리스너 프로세스를 root로 구동하면, 침해 시 OS 전체 권한으로 확장될 위험이 커진다. 표준은 전용 OS 계정(예: oracle)으로 구동하는 것이다.

확인 방법(운영 점검 + 보조 SQL)

# (Linux 예시) DB/리스너 프로세스 소유자 확인
ps -ef | egrep "pmon|tnslsnr|ora_" | egrep -v egrep

# (Grid/Restart 사용 시 예시) 리소스 실행 계정 확인
crsctl stat res -t
srvctl status database -d <DB_UNIQUE_NAME>
srvctl status listener

-- (보조) DB에서 OS 계정 정보가 세션에 남는지 확인(접속 사용자 기준)
SELECT username, osuser, machine, program, COUNT(*) AS session_cnt
FROM v$session
WHERE username IS NOT NULL
GROUP BY username, osuser, machine, program
ORDER BY session_cnt DESC;

조치 방법(권고)

# 원칙: root가 아닌 전용 OS 계정(예: oracle)로 구동
# 1) 서비스/스크립트 실행 계정 점검
# 2) systemd / init 스크립트의 User= 설정(또는 실행 주체) 변경
# 3) 파일/디렉터리 소유권과 권한 재정비 후 재기동

# (예시) systemd 유닛에서 전용 계정 사용
# [Service]
# User=oracle
# Group=oinstall

* 이 항목은 SQL보다 운영 설정 영향이 크다. 변경 전 유지보수 창구(점검/롤백) 확보를 권장한다.

D-08 안전한 암호화 알고리즘 사용(상/3)

암호화는 “있다/없다”보다 “무슨 알고리즘·어떤 구간(통신/저장/비밀번호)”에 적용되는지가 핵심이다. 운영 환경에서는 특히 네트워크 암호화(TLS/네이티브 암호화)와 패스워드 버전 점검이 우선이다.

확인 방법(SQL + 설정 파일)

-- 1) 사용자별 패스워드 버전 확인(취약한 구버전 허용 여부 점검)
SELECT username, account_status, password_versions
FROM dba_users
WHERE oracle_maintained = 'N'
ORDER BY username;

-- 2) (가능 시) 암호화/지갑 상태 점검(TDE 사용 환경)
-- 뷰/컬럼은 환경에 따라 다를 수 있음
SELECT *
FROM v$encryption_wallet;

# 3) 네트워크 암호화는 sqlnet.ora / listener.ora 설정 확인이 핵심
# 위치 예시: $ORACLE_HOME/network/admin/sqlnet.ora

# 확인 포인트 예시(환경 정책에 맞게 적용)
# SQLNET.ENCRYPTION_SERVER = REQUIRED
# SQLNET.ENCRYPTION_TYPES_SERVER = (AES256)
# SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
# SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256)
# SSL_VERSION, WALLET_LOCATION 등 TLS 설정

조치 방법(권고)

-- 1) 구버전 패스워드 허용이 남아 있으면, 계정별 비밀번호 변경으로 상향 유도
ALTER USER SOME_USER IDENTIFIED BY "강력한비밀번호_예시!2026";

-- 2) 네트워크 암호화/무결성은 sqlnet.ora에서 정책 강제(예시)
# SQLNET.ENCRYPTION_SERVER = REQUIRED
# SQLNET.ENCRYPTION_TYPES_SERVER = (AES256)
# SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
# SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256)

-- 3) 저장 데이터 암호화(TDE) 사용 환경이면 지갑/키 관리 정책까지 포함해 운영 표준화

D-09 로그인 실패 횟수 기반 잠금 정책 설정(중/2)

무차별 대입(브루트포스)을 억제하는 기본 장치다. 실패 횟수, 잠금 시간, 유예기간을 기관 정책에 맞게 통일한다.

확인 방법(SQL)

-- 프로파일별 잠금 관련 정책 확인
SELECT profile, resource_name, limit
FROM dba_profiles
WHERE resource_name IN ('FAILED_LOGIN_ATTEMPTS','PASSWORD_LOCK_TIME','PASSWORD_GRACE_TIME')
ORDER BY profile, resource_name;

-- 계정 상태에서 LOCK/EXPIRED 여부 확인
SELECT username, account_status, profile
FROM dba_users
WHERE oracle_maintained = 'N'
ORDER BY account_status, username;

조치 방법(SQL 예시)

-- 표준 프로파일에 잠금 정책 적용(예시 값은 정책에 맞게 조정)
ALTER PROFILE SECURE_PROFILE LIMIT
  FAILED_LOGIN_ATTEMPTS 10
  PASSWORD_LOCK_TIME    1/24
  PASSWORD_GRACE_TIME   7;

-- 적용(예시)
ALTER USER APP_USER PROFILE SECURE_PROFILE;

-- 잠긴 계정 해제(필요 시, 승인 후)
ALTER USER APP_USER ACCOUNT UNLOCK;

D-10 원격에서 DB 서버로의 접속 제한(상/3)

DB 서버의 원격 접속은 공격면을 급격히 키운다. 원칙은 관리망/전용 구간으로 제한하고, 방화벽/보안그룹/프록시/WAF를 통해 허용 IP·포트·프로토콜을 명확히 통제하는 것이다.

확인 방법(SQL + 네트워크 점검)

-- 1) 현재 접속 세션의 접속 출처(호스트/프로그램) 분포 확인
SELECT username, machine, program, COUNT(*) AS session_cnt
FROM v$session
WHERE username IS NOT NULL
GROUP BY username, machine, program
ORDER BY session_cnt DESC;

-- 2) 리스너/포트 정보는 SQL만으로 한계가 있어 OS에서 확인 권장
-- (Linux 예시)
# lsnrctl status
# netstat -tnlp | grep 1521
# ss -tnlp | grep 1521

조치 방법(권고)

# 1) 네트워크 차단이 1순위
# - DB 포트(기본 1521) 인터넷 직접 노출 금지
# - 허용 IP/대역만 관리망에서 접근
# - Bastion/VPN 경유, MFA 적용(가능 시)

# 2) 리스너 측 접근제어(환경에 따라 적용)
# - Valid Node Checking(허용 호스트/IP 제한) 사용 가능 여부 검토
# - listener.ora / sqlnet.ora 정책으로 통제 보강

# 3) 운영 표준
# - "누가(계정) / 어디서(망·호스트) / 무엇으로(program) / 언제" 접속하는지 증빙 유지