OBIEE 로그인 실패 추적: 접속 IP와 사용자 ID를 WebLogic 로그로 남기기

Table of Contents

보안 감사에서 “로그인에 실패한 계정, 시각, 접속한 IP를 제출하라”는 요청을 받으면 OBIEE 기본 설정만으로는 답하기 어렵습니다. 사용자 ID가 남는 로그에는 IP가 없고, IP가 남는 로그에는 사용자 ID가 없습니다. 2019년 3월에 OBIEE 11g(11.1.1.7.x, WebLogic 10.3.6)와 12c(12.2.1.4) 시험 환경에서 로그인 실패를 재현하면서 어떤 로그에 무엇이 남는지 확인했고, 이 글은 그 결과를 정리한 것입니다.

2024년 9월 Notion에 영어로 정리했던 글을 옮기면서 2026년 10월에 Oracle 문서로 다시 확인했습니다. 원본 본문에 있던 로그 예시 일부가 당시 스크린숏과 맞지 않아, 이번 글의 로그는 모두 스크린숏에 실제로 찍힌 내용으로 바꿨습니다(사용자 ID와 IP만 바꿈). OBIEE의 후속 제품인 Oracle Analytics Server(OAS)도 WebLogic 12.2.1.4 위에서 동작하므로 WebLogic 쪽 설정은 같은 방식으로 적용할 수 있습니다. 다만 OAS에서 직접 재현하지는 않았습니다.

결론부터: 로그별로 남는 정보

로그	클라이언트 IP	사용자 ID	실패 여부	시각
`access.log` (Extended 형식)	있음	없음	12c: 있음(`login-failed.jsp` 이동) 11g: 구분 어려움	있음
`DefaultAuditRecorder.log` (Auditing provider)	없음	있음	있음(`Severity =FAILURE`)	있음
`bi_server1-diagnostic.log`	없음	없음	있음	있음

한 로그에 IP와 사용자 ID가 함께 남지는 않습니다. 그래서 access.log의 IP와 DefaultAuditRecorder.log의 사용자 ID를 시각으로 맞춰 보는 것이 현실적인 방법입니다. 시험에서는 두 로그의 시각이 초 단위까지 일치했습니다. 같은 초에 여러 사람이 로그인하면 짝을 확정할 수 없다는 한계는 있습니다.

1. access.log에 클라이언트 IP 남기기

WebLogic HTTP 액세스 로그의 기본 형식(common)은 필드를 고를 수 없습니다. Extended 형식으로 바꾸고 필드를 지정합니다. OBIEE 화면 요청을 받는 Managed Server(bi_server1)에 설정합니다.

관리 콘솔에서 Lock & Edit
Environment > Servers > bi_server1 > Logging > HTTP
HTTP access log file enabled가 켜져 있는지 확인
Advanced에서 Format을 Extended로 바꾸고 Extended Logging Format Fields에 아래 값을 입력
Save, Activate Changes 후 bi_server1 재시작

date time c-ip s-ip cs-method ctx-ecid ctx-rid cs-uri sc-status bytes

재시작: 로그 형식(LogFileFormat) 변경은 재시작이 필요한 속성입니다(WebLogic 12.2.1.4 MBean 메타데이터 restartNeeded: true).
시각: 기본값(Log time in GMT 꺼짐)에서는 서버 현지 시각으로 남습니다. 감사 로그와 시각을 맞출 때 그대로 비교하면 됩니다.
사용자 ID 필드는 쓸 수 없음: 당시 cs-authuser, cs-username도 넣어 봤지만 값이 각각 null, -로만 찍혔습니다. 두 필드는 WebLogic 문서의 Extended Log Format 필드 목록에 없고, Oracle 지원 문서(Doc ID 2384515.1, “Missing Username After Setting Up HTTP Extended Log Format”)도 Extended 형식에서는 사용자 ID가 남지 않는 문제를 다룹니다. 그래서 위 필드 목록에서 뺐습니다.

2. 실패한 사용자 ID 남기기: Auditing provider

사용자 ID는 WebLogic Auditing provider(DefaultAuditor)의 DefaultAuditRecorder.log에 남습니다. 추가 방법은 WebLogic 감사(Audit) 설정에 정리했습니다. 여기서는 로그인 실패에 필요한 부분만 짚습니다.

Security Realms > myrealm > Providers > Auditing > New에서 Type DefaultAuditor로 추가합니다.
로그인 실패는 FAILURE 등급입니다. Severity는 지정한 등급과 그보다 순위가 높은 이벤트를 기록하므로, 기본값 ERROR만으로도 FAILURE가 기록됩니다. 다만 SUCCESS 이벤트도 함께 쌓입니다.
실패만 남기려면 Severity를 CUSTOM으로 두고 Failure Audit Severity Enabled만 켭니다. 당시 시험에서는 모든 등급을 켰더니 정상 권한 확인(Authorization Audit Event V2, SUCCESS) 기록이 대부분을 차지했습니다.
provider 추가는 동적 변경이 아니므로, 보안 영역 자동 재시작이 꺼져 있다면 서버를 재시작해야 합니다.

3. 로그 비교: 12c

같은 PC(10.10.1.64)에서 11:44:17에 user01, 11:44:30에 weblogic으로 틀린 비밀번호를 넣었을 때의 기록입니다.

access.log: 로그인 POST 뒤에 login-failed.jsp로 이동한 기록이 남아 실패 시각과 IP를 알 수 있습니다. 사용자 ID 칸(cs-authuser, cs-username)은 비어 있습니다.

#Fields: date time cs-authuser cs-username c-ip s-ip cs-method ctx-ecid ctx-rid cs-uri sc-status bytes
2019-03-10 11:44:17 null - 10.10.1.64 10.10.1.102:7780 POST 8c10abaf-6a1e-4a9c-9d7b-11532b3c6639-00000579 0 /bi-security-login/login 302 681
2019-03-10 11:44:17 null - 10.10.1.64 10.10.1.102:7780 GET 8c10abaf-6a1e-4a9c-9d7b-11532b3c6639-0000057a 0 /bi-security-login/login-failed.jsp?msi=false&amp;redirect=... 200 1167
2019-03-10 11:44:30 null - 10.10.1.64 10.10.1.102:7780 POST 8c10abaf-6a1e-4a9c-9d7b-11532b3c6639-00000580 0 /bi-security-login/login 302 681
2019-03-10 11:44:30 null - 10.10.1.64 10.10.1.102:7780 GET 8c10abaf-6a1e-4a9c-9d7b-11532b3c6639-00000581 0 /bi-security-login/login-failed.jsp?msi=false&amp;redirect=... 200 1167

DefaultAuditRecorder.log: 같은 시각에 실패한 사용자 ID가 남습니다. IP는 없습니다.

#### Audit Record Begin <Mar 10, 2019 11:44:17 AM> <Severity =FAILURE> <<<Event Type = Authentication Audit Event><user01><AUTHENTICATE>>> <FailureException =javax.security.auth.login.FailedLoginException: [Security:090938]Authentication failure: The specified user failed to log in. javax.security.auth.login.FailedLoginException: [Security:090302]Authentication Failed: User specified user denied> Audit Record End ####
#### Audit Record Begin <Mar 10, 2019 11:44:30 AM> <Severity =FAILURE> <<<Event Type = Authentication Audit Event><weblogic><AUTHENTICATE>>> <FailureException =javax.security.auth.login.FailedLoginException: [Security:090938]Authentication failure: The specified user failed to log in. javax.security.auth.login.FailedLoginException: [Security:090302]Authentication Failed: User specified user denied> Audit Record End ####

bi_server1-diagnostic.log: 인증 실패(OBI-SEC-00020)는 남지만 사용자 ID와 IP는 없습니다(userId: <anonymous>).

[2019-03-10T11:44:30.627-05:00] [bi_server1] [NOTIFICATION] [OBI-SEC-00020] [oracle.bi.security.authentication] [tid: [ACTIVE].ExecuteThread: '38' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: 8c10abaf-6a1e-4a9c-9d7b-11532b3c6639-...] ... The specified user credentials could not be authenticated.
javax.security.auth.login.LoginException: [Security:090938]Authentication failure: The specified user failed to log in. javax.security.auth.login.FailedLoginException: [Security:090302]Authentication Failed: User specified user denied

4. 로그 비교: 11g

11g는 로그인 실패에도 /analytics/saw.dll?bieehome POST가 200으로 끝나서 access.log만으로는 실패를 구분하기 어렵습니다. 같은 초에 서버 자신(10.10.1.103)이 /bisecurity/service를 호출해 500을 받은 기록이 함께 남고, 11g에서는 ctx-ecid, ctx-rid가 -로 찍혔습니다.

2019-03-10 13:28:33 - - 10.10.1.64  10.10.1.103:7780 POST - - /analytics/saw.dll?bieehome 200 3228
2019-03-10 13:28:34 - - 10.10.1.103 10.10.1.103:7780 POST - - /bisecurity/service 500 512
2019-03-10 13:28:34 - - 10.10.1.64  10.10.1.103:7780 POST - - /analytics/saw.dll?bieehome 200 10852

DefaultAuditRecorder.log에는 같은 13:28:34에 실패한 사용자 ID가 남습니다.

#### Audit Record Begin <Mar 10, 2019 1:28:34 PM> <Severity =FAILURE> <<<Event Type = Authentication Audit Event><user01><AUTHENTICATE>>> <FailureException =javax.security.auth.login.FailedLoginException: [Security:090304]Authentication Failed: User user01 javax.security.auth.login.FailedLoginException: [Security:090302]Authentication Failed: User user01 denied> Audit Record End ####

bi_server1-diagnostic.log에는 BI Security Service의 인증 거부가 남지만 사용자 ID와 IP는 없습니다.

[2019-03-10T13:28:34.102-04:00] [bi_server1] [ERROR] [OWS-04086] [oracle.webservices.service] ... [APP: bisecurity#11.1.1] oracle.webservices.provider.ProviderException: javax.xml.ws.WebServiceException: BI Security Service Access Denied - credentials supplied in SOAP Message header failed authentication

5. 로드밸런서 뒤에 있을 때: 원래 클라이언트 IP

로드밸런서나 프록시를 거치면 c-ip에는 로드밸런서 주소가 남습니다. 로드밸런서가 원래 주소를 X-Forwarded-For 헤더에 넣어 준다면, WebLogic의 사용자 정의 필드로 이 헤더를 기록할 수 있습니다. 아래는 WebLogic 문서의 사용자 정의 필드 예제(CustomELFLogger)를 X-Forwarded-For용으로 바꾼 것입니다.

// GWXFF.java
import weblogic.servlet.logging.CustomELFLogger;
import weblogic.servlet.logging.FormatStringBuffer;
import weblogic.servlet.logging.HttpAccountingInfo;

public class GWXFF implements CustomELFLogger {
    public void logField(HttpAccountingInfo metrics, FormatStringBuffer buff) {
        buff.appendValueOrDash(metrics.getHeader("X-Forwarded-For"));
    }
}

# 컴파일에는 weblogic.jar가 필요합니다(원본 글에는 -cp가 빠져 있었습니다)
javac -cp $ORACLE_HOME/wlserver/server/lib/weblogic.jar GWXFF.java
jar cvf GWXFF.jar GWXFF.class

JAR를 서버 시작 CLASSPATH에 추가합니다. Oracle 문서는 이 클래스를 웹 애플리케이션이나 엔터프라이즈 애플리케이션 안에 넣지 말라고 안내합니다. 생성 스크립트를 고치는 대신 <DOMAIN_HOME>/bin/setUserOverridesLate.sh에서 POST_CLASSPATH에 덧붙이는 방법을 권합니다(boot.properties 글의 setUserOverrides 설명 참고). setUserOverrides 계열 스크립트는 WebLogic 12.1.2부터 있으므로, OBIEE 11g(WebLogic 10.3.6)에서는 도메인의 시작 환경 스크립트에서 CLASSPATH를 지정해야 합니다.
Extended Logging Format Fields에 x-GWXFF를 추가합니다. 사용자 정의 필드 이름은 x- 뒤에 클래스의 정규화된 이름을 씁니다.
서버를 재시작합니다.

# setUserOverridesLate.sh
POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}/u01/custom/GWXFF.jar"
export POST_CLASSPATH

# Extended Logging Format Fields
date time c-ip x-GWXFF s-ip cs-method ctx-ecid ctx-rid cs-uri sc-status bytes

X-Forwarded-For는 클라이언트가 직접 보낼 수도 있는 헤더이므로, 로드밸런서가 이 값을 덮어쓰도록 설정돼 있을 때만 신뢰할 수 있습니다. 원본 글에서 인용했던 cs(X-Forwarded-For) 필드 방식은 외부 블로그에서 소개된 방법으로, WebLogic 12.2.1.4 문서의 필드 목록에서는 확인되지 않아 여기서는 문서에 있는 사용자 정의 필드 방식을 썼습니다. 이 사용자 정의 필드는 당시 스크린숏에 결과가 남아 있지 않아, 적용 후 access.log에 값이 찍히는지 꼭 확인하세요.

주의할 점

Oracle 문서는 Auditing provider가 기록하는 이벤트가 적어도 성능에 영향을 준다고 안내합니다. 사용자 정의 로그 필드 클래스에서도 DB 조회나 네트워크 호출처럼 느린 작업을 하지 말라고 합니다. 모든 HTTP 요청마다 실행되기 때문입니다.
로그 양이 늘어나므로 보관 기간과 디스크 용량을 함께 계획하세요.
운영에 적용하기 전에 시험 환경에서 로그인 실패를 직접 재현해 세 로그를 비교해 보세요.

정리

OBIEE에서 로그인 실패의 IP와 사용자 ID를 한 줄로 얻는 설정은 없습니다. access.log를 Extended 형식으로 바꿔 IP를 남기고, Auditing provider로 실패한 사용자 ID를 남긴 뒤, 두 로그를 시각으로 맞춰 봅니다. 12c는 login-failed.jsp 이동으로 실패 요청을 바로 찾을 수 있어 11g보다 맞춰 보기가 쉽습니다.

WebLogic 감사 설정 전반은 WebLogic 감사(Audit) 설정, OAS 로그인 지연 진단은 AD 로그인은 빠른데 weblogic만 느릴 때에서 다뤘습니다.