SSISO Community

개요

배포된 애플리케이션을 보안 위협으로부터 보호하려면 체계적인 접근 방법이 필요합니다. 공격 패턴 및 취약성을 확인하면 적절한 대응책을 통해 이러한 문제를 처리할 수 있습니다. 이에 필요한 접근 방식의 기본적인 특징은 다음과 같습니다.

What to protect
이것은 영구 저장소와 같은 자산 확인과 관련됩니다.
From whom to protect
자산을 위태롭게 하는 악의적 액션과 같은 가능한 모든 공격으로부터 리소스를 보호해야 합니다.
How to protect
취약점(예: 버그 등) 및 이러한 취약점을 악용할 수 있는 공격 가능성을 발견하면 대응책을 강구하여 위험을 최소화합니다.

이 문서에서는 WLPlatform 8.1을 사용하여 설계, 개발 및 배포된 n-tier 애플리케이션에 대한 보안 위협으로부터 보호 방법을 설명합니다. 위협을 확인하고 위험 상태를 이해하고 나면 새로운 위협을 확인하고 이 위협에 대한 대응책을 향상시기 위한 작업을 정기화하게 됩니다. 다음 장에서는 이러한 접근 방법에 대해 자세히 살펴보겠습니다.

보안 위협에 대한 보호 프로세스
WebLogic Platform 애플리케이션 자산 확인
애플리케이션 아키텍처 분석: 샘플 배포 시나리오
보안 프로파일 정의
보안 위협 확인
보안 위협 정보에 따른 보안 강화
요약
부록: 정의
감사의 말씀

위협 보호 프로세스. 위협 보호 프로세스는 다음 단계로 구성됩니다.:

WebLogic Platform 애플리케이션 자산 확인
데이터베이스 테이블, 설정 파일, 보안 비밀 사항 등 애플리케이션에 배포되어 있는 중요한 리소스를 확인합니다.
애플리케이션 아키텍처 분석
애플리케이션 아키텍처를 확인하면 애플리케이션을 더 작은 컴포넌트로 분해하여 정교한 수준에서 다음과 같은 속성을 쉽게 확인할 수 있습니다.
- 각 컴포넌트에 대한 외부 액세스 지점
  "보호 경계(Protected Boundary)" 및 "진입점(Entry Points)"은 각 컴포넌트 및 전반적인 애플리케이션에 대한 액세스 지점을 확인하기 위해 필요합니다. 또한 애플리케이션 요구 사항에 따라 여러 "보호 경계(Protected Boundary)" 레이어를 배포하는 것도 가능합니다.
- 데이터 흐름 (Data Flow)
  기밀성 및 무결성을 유지해야 하는 컴포넌트 내에서의 데이터 흐름. 데이터 흐름이란 컴포넌트 내의 통신 채널을 말합니다.
- 특권코드 (Privileged Code)
  악의적 의도로 액세스하거나 사용될 수 있는 애플리케이션 내부의 특권코드.
위에서 언급한 속성을 종합하면 애플리케이션 전반에 대한 위협을 확인하는 데 도움이 됩니다. 다음 예제는 이러한 분석 과정을 보여줍니다.

그림 1의 샘플 아키텍처는 도메인 D1과 D2 두 가지의 주요 컴포넌트로 구성되어 있습니다. D1을 자세히 살펴보겠습니다.

D1은 관리 서버(Managed Server)를 사용하는 WebLogic 클러스터입니다. 도메인을 둘러싼 보호 경계에는 다음과 같은 진입점이 있습니다.
- OS로부터 열려있는 포트.
  차단하려면 IP 방화벽이 필요합니다.
- 크리티컬한 비즈니스 동작을 호출하는 외부 사용자를 위해 열려있는 SSL 포트.
  하드웨어 프록시는 SSL 인증에서 여러 클라이언트에 대한 주고받기(핸드셰이킹) 프로세스를 신속하게 처리하기 위해 사용됩니다. 프록시에서 개별 관리 서버(Managed Server)와 통신하기 위해 사전 구축된 SSL 커넥션이 사용됩니다.
- 크리티컬하지 않은 비즈니스 동작(예: 카탈로그 검색)을 호출하는 외부 사용자를 위해 열려있는 HTTP 포트.
- - 암호로 보호된 클라이언트는 크리티컬하지 않은 동작(예: 카탈로그 검색)만 실행할 수 있는 반면 다른 크리티컬한 동작은 SSL 상에서 보호됩니다.
  - XML 방화벽을 사용하는 컨텐츠 유효성 검사 기능은 암호로 보호된 클라이언트가 크리티컬한 웹 서비스를 호출하지 못하도록 합니다.
  - 외부 T3 클라이언트 액세스는 컨텐츠의 유효성을 검사할 수 없기 때문에 WebLogic 커넥션 필터에서 거부됩니다.
D1 및 D2 컴포넌트 간 데이터 흐름은 크리티컬한 비즈니스 동작에 대해 SSL을 사용하여 보호해야 합니다. 프록시 및 관리 대상 서버(Managed Server) 간 통신은 한 번 구축하면 향후 모든 요청에서 재사용됩니다. 이로써 SSL 핸드셰이킹 시간이 정규 요청 처리 시간과 분리됩니다. 전송 레이어에서의 스푸핑은 SSL 핸드셰이킹을 사용해서만 보호할 수 있다는 사실을 이해해야 합니다.

컴포넌트 내의 내부적 위협은 특권코드에 대한 액세스와 관련이 있습니다. BEA에서 나온 일련의 시스템 수준의 jar와 관련된 유효한 액세스 정책은 크리티컬한 리소스에 대해 문제를 일으킬 수 있는 액세스를 가능하게 할 수도 있습니다. 다음은 특권 코드의 다양한 세그먼트에 대한 내부 위협을 방지하기 위한 지침입니다.
- 애플리케이션/시스템 대기열에 액세스하는 코드
  weblogic.jar, webservices.jar 및 기타 WLI 전용 jar는 Java 액세스 정책을 사용하여 보호해야 합니다. 그렇지 않으면 권한 없는 코드가 리플렉션을 사용하여 대기열과 같이 보호된 리소스에 액세스하기 위해 시스템 레벨의 jar를 악용할 수 있습니다.
- 설정 리소스에 액세스하는 코드
  weblogic.jar, "webservices.jar", WLI 전용 jar 및 WLP 전용 jar는 설정에 관련된 리소스에 액세스합니다. 이러한 jar는 Java 액세스 정책을 사용하여 보호해야 합니다.
- 모든 애플리케이션 레벨 jar에 대해 "KERNELID"에 대한 액세스 권한을 거부해야 합니다. Java 정책 파일에서 "weblogic.kernelPermission"을 사용하여 "KERNELID"에 대한 액세스 권한을 거부합니다.
D1과 마찬가지로, 특히 외부 액세스 지점, 데이터 흐름 및 액세스 권한과 관련된 D2의 모든 세부 정보도 처리해야 합니다. 다음 단계에서는 이러한 정보를 사용하여 애플리케이션 분석을 완료하는 방법에 대해 알아봅니다.
애플리케이션 아키텍처에 대한 보안 프로파일 레이아웃.
배포된 모든 애플리케이션에 대한 보안 프로파일은 각 애플리케이션이 공통으로 지니고 있는 취약성에 근거해서 만들어집니다. 프로파일은 이러한 취약성 문제를 해결하기 위한 설계 및 구현 접근 방법을 규명합니다. 애플리케이션 아키텍처 분석에서 이용할 수 있는 정보는 보안 프로파일을 만들기 위한 올바른 컨텍스트를 제공합니다.

다음은 보안 프로파일에 대한 일련의 필수 요소를 요약한 것입니다.
- 입력 유효성 검사
- 인증
- 권한 부여
- 설정 관리
- 세션 관리
- 암호화 지원
- 예외 보고
- 감사 및 로깅
- 파라미터 조작
위협 확인.
배포된 애플리케이션에 대한 보안 위협 및 관련된 위험을 확인합니다. 보다 체계적이고 재사용 가능한 접근 방법으로 공격 기록을 문서화하려면 "공격(Attack) 트리"를 사용합니다. 자세한 내용은 정보 보안 및 신뢰성을 위한 공격 모델링(Attack Modeling for Information Security and Reliability)을 참조하십시오.
보안 위협 정보에 기반한 보안 강화.
보안 위협에 관한 정보를 적절히 사용하면 배포된 애플리케이션에 대한 보안을 향상시킬 수 있습니다.

이에 대한 지침은 다음 단원에서 제공됩니다.

WebLogic Platform 애플리케이션 자산 확인

WLPlatform 컴포넌트를 갖춘 WebLogic 도메인은 다양한 유형의 리소스로 구성되어 있습니다. 이러한 리소스 중 대부분은 크리티컬한 자산으로 간주되며 보호되어야 합니다. 크리티컬 리소스에는 다음이 포함됩니다.

데이터베이스 테이블
- 시스템 테이블
- BEA의 애플리케이션 테이블
데이터베이스 풀
- 디폴트 풀
- 애플리케이션 전용 풀
디스크 상의 설정 파일
LDAP 저장소
개인 키 저장소
WLI의 커넥터 리소스
WebLogic Platform 컴포넌트에 대한 JNDI 리소스

추가 리소스 목록은 다음을 참조하십시오.
http://edocs.bea.com/wls/docs81/secwlres/types.html#1209988

애플리케이션 아키텍처 분석: 샘플 배포 시나리오

배포 시나리오는 그림 1에 설명되어 있습니다. 이 애플리케이션은 다음 두 가지 논리적 컴포넌트로 구성되어 있습니다.

D1 : Portal 도메인
D2 : WLI 도메인

다음은 각 도메인에 대한 기능 및 데이터 흐름에 대한 설명입니다.

D1
- D1은 웹 서비스, HTTP/HTTPS를 통한 브라우저 기반 요청 및 인터넷으로부터의 T3s 요청을 수신합니다.
- D1은 HTTP/HTTPs를 통한 웹 서비스, T3 및 T3s를 통한 JMS, T3 및 T3s를 통한 EJB 호출을 통해 D2와 데이터를 주고 받습니다.
- D1은 DB 컨트롤 및 맞춤형 컨트롤을 사용하여 크리티컬한 비즈니스 동작을 실행합니다.
D2
- D2는 웹 서비스, HTTP/HTTPS를 통한 B2B 및 인터넷으로부터의 T3s 요청을 수신합니다.
- D2는 HTTP/HTTPs를 통한 웹 서비스, T3 및 T3s를 통한 JMS, T3 및 T3s를 통한 EJB 호출을 통해 D1과 데이터를 주고 받습니다.
- D2는 프로세스 컨트롤 및 맞춤형 컨트롤을 사용하여 크리티컬한 비즈니스 프로세스를 실행합니다.

참고: 빨간색 화살표는 SSL를 통한 데이터 흐름을 나타내고 검정색 화살표는 비 SSL 통신을 나타냅니다. 점선으로 된 화살표는 D2에서 D1 컴포넌트로의 통신을 나타냅니다.

다음을 유의하십시오.

각 도메인은 다음을 포함하는 DMZ와 관련됩니다.
- IP 방화벽
- 프록시 서버
IP 방화벽은 HTTP 및 SSL 기반 통신용으로 서로 다른 두 개의 포트를 사용해야 합니다. 두 방화벽은 다음과 같은 이유에서 유사하게 구성됩니다.
- D1 및 D2 모두 비슷한 중요도를 가진 리소스로 구성되어 있습니다.
- 각 컴포넌트는 HTTP를 통해 인터넷에서 액세스할 수 있습니다. 예를 들면 다음과 같습니다.
- - D1은 웹 브라우저 및 웹 서비스에서 액세스할 수 있습니다.
  - D2는 웹 서비스 및 B2B 파트너에서 액세스할 수 있습니다.
- 바람직하지 않은 포트 검색에 대한 보호가 필요합니다.
- 각 컴포넌트는 다른 컴포넌트와 상호 작용합니다. 하나의 컴포넌트에 대한 보안이 취약할 경우 애플리케이션 전체에 대해 악의적인 사용자가 외부에서 쉽게 액세스할 수 있습니다. 각 컴포넌트는 상대 컴포넌트를 통해 "호출"될 수 있기 때문에 악의적인 외부 사용자가 보안이 취약한 컴포넌트를 통해 더욱 강력한 외부 방화벽에 의해 보호되는 컴포넌트를 호출을 할 수 있습니다. 이 문제는 다음과 같이 해결할 수 있습니다.
- - 모든 컴포넌트는 동일한 보안 보호 수준을 유지해야 합니다. 동일하게 구성된 방화벽 및 프록시를 사용하면 이런 문제를 방지할 수 있습니다. 그림 1은 이러한 구성을 보여줍니다.
  - 또는 보안 보호가 다소 취약한 컴포넌트의 경우 모든 클라이언트 자격 증명에 대한 유효성 검사를 더 강력한 보안 조건에 위임하도록 합니다.
  각 방화벽은 통신 유형에 따라 고유한 포트를 선택해야 합니다. 그러면 또 다른 보호 레이어가 생겨나 전체 시스템이 한 번에 노출되는 위험을 줄일 수 있습니다.
  
  특정 컴포넌트가 다른 컴포넌트에 비해 더 크리티컬한 리소스를 보호해야 하는 시나리오에서는 이러한 특정 예제가 적합하지 않을 수 있습니다. 위협에 민감한 컴포넌트에는 더욱 엄격한 방화벽이 적합하고 직접적인 외부 액세스를 허용하지 말아야 합니다. 보안 기능이 서로 다른 여러 방화벽을 사용하면 "보안을 강화"할 수 있습니다. 방화벽 보호 이외에 애플리케이션의 모든 컴포넌트에 액세스하려는 모든 사용자에게 중앙 집중형 인증 서비스를 실행합니다. 그림 1에 언급된 프록시 서버 P1 및 P2는 이러한 목적을 수행하도록 동일하게 구성되어 있습니다.
관리 서버(Managed Server)는 각각 로컬 XML 방화벽과 관련됩니다. 비 SSL 포트에 도착하는 모든 메시지는 강력한 컨텐츠 기반 필터링을 위해 XML 방화벽으로 전달됩니다. 이 경우 웹 서비스 호출을 통한 정교한 액세스 제어가 보장됩니다. 예제는 다음과 같습니다.
- 암호로 보호되는 클라이언트는 카탈로그 검색과 같은 크리티컬하지 않은 동작만 실행할 수 있는 반면 다른 크리티컬한 동작은 SSL을 통해 보호됩니다.
- 컨텐츠 유효성 검사 기능은 암호로 보호된 클라이언트가 크리티컬한 웹 서비스를 호출하지 못하도록 합니다.
- 컨텐츠의 유효성 검사를 할 수 없기 때문에 모든 외부 T3 클라이언트 액세스가 거부됩니다. 외부 T3 커넥션은 커넥션 필터를 사용하여 거부할 수 있습니다.
프록시 서버(예: 그림 1의 P1 및 P2)는 각각 포트 443 및 444를 사용하여 SSL 기반 인증에 대해 구성됩니다. 암호 기반 인증은 각각 포트 80 및 81을 사용하여 구성됩니다. 인증되면, SAML 기반 토큰과 같은 보안 토큰을 메시지의 통합 파트로 사용하여 보안 ID를 관리 서버(Managed Server)에 전파합니다. HTTP 및 T3 트래픽의 로드 밸런싱 또한 프록시를 통해 수행됩니다.
다른 모든 인바운드 포트는 방화벽을 통해 차단해야 합니다. 아웃바운드 포트는 인터넷 클라이언트를 대상으로 하는 콜백(웹 서비스)을 지원하기 위해 열어두어야 합니다. NAT와 같은 기술을 사용하여 내부 포트가 직접 노출되지 않도록 해야 합니다.
포트 443 및 444에서의 모든 요청에 대한 SSL에 프록시를 구성해야 합니다.
어떠한 외부 T3 클라이언트도 허용되지 않지만 외부 T3s 클라이언트는 허용됩니다.

참고: 모든 클러스터 도메인은 적절한 방화벽 기술로 보호해야 합니다.

그림 1

보안 프로파일 정의

애플리케이션에 대한 보안 프로파일은 이미 확인된 취약성에 기반하여 만들 수 있습니다. 보안 프로파일에 사용된 대응책은 다음으로 구성됩니다.

입력 유효성 검사

버퍼 오버런

버퍼 오버런 취약성은 "서비스 거부(DOS)" 공격 또는 코드 삽입으로 이어질 수 있습니다. "서비스 거부(DOS)" 공격은 프로세스 크래시를 초기화할 수 있고 코드 삽입은 공격자가 삽입한 코드를 실행하기 위해 프로그램 실행 주소를 변경합니다.

버퍼 오버런 취약성의 예방책은 다음과 같습니다.
- 버퍼가 포함된 모든 메시지의 길이를 확인합니다. (JNI 코드에만 적용 가능.)
- 버퍼 오버런에 대한 최신 JVM 패치를 적용합니다.
SQL 삽입

SQL 삽입 공격은 데이터베이스에서 임의의 명령을 실행하기 위해 사용될 수 있습니다. 이 공격은 대부분 애플리케이션이 사용자 입력을 사용하여 데이터베이스에 액세스하기 위한 동적 SQL 문을 구성하는 경우 발생할 수 있습니다. 몇 가지 예방책은 다음과 같습니다.
- JDBC 사양이 SQL 삽입 처리에 대해 명확하지 않기 때문에 SQL 삽입에 대해 충분한 공간이 없이 "PreparedStatement"가 적용됐는지 확인하기 위해 DB 드라이버를 테스트합니다.
- SQL 삽입을 방지하려면 항상 입력의 유효성을 검사해야 합니다.
- 입력의 유효성을 검사하지 않고 JDBC 패키지를 일괄 실행하면 SQL 삽입에 취약해집니다.
- "최소한의 권한"을 사용하여 데이터베이스 테이블에 대한 액세스 제어를 설계해야 합니다. 기본적인 매핑은 커넥터 아키텍처를 사용하여 구현되어야 합니다. 그러면 서로 다른 액세스 권한을 가진 WLS ID에 상응하는 일련의 데이터베이스 ID를 갖는 데 도움이 됩니다.
Cross-Site Scripting (XSS)

XSS 공격은 브라우저가 트러스트된 웹 사이트에 연결되어 있는 동안 악의적인 코드가 사용자의 브라우저에서 실행되도록 할 수 있습니다. 이 공격은 애플리케이션 자체가 아니라 애플리케이션 사용자를 대상으로 하지만 애플리케이션을 사용하여 공격합니다. 이 공격에 대한 가장 일반적인 예방책은 다음과 같습니다.
- URL 문자열 유효성 검사 같은 입력 유효성 검사
- 크로스 사이트 스크립팅을 방지하기 위한 인코딩
정규화(Canonicalization)

이름과 관련된 다양한 입력 양식을 동일한 표준 이름(정식 이름)으로 바꾸는 것을 정규화(canonicalization)라고 합니다. 애플리케이션 코드는 입력되어 프로그램으로 전달된 리소스의 이름에 기반하여 보안 결정을 할 경우 정규화 문제에 민감합니다. 파일, 경로 및 URL은 각각 동일한 이름을 표현하는 다양한 방식이 있기 때문에 정규화에 취약한 리소스 타입입니다. 몇 가지 대응책은 다음과 같습니다.
- 가능한 파일 이름 입력을 피하고 사용자가 변경할 수 없는 절대 파일 경로를 사용합니다.
- 문자 인코딩이 입력을 표시하는 방법을 제한하도록 올바로 설정되어 있는지 확인합니다. 애플리케이션의 Web.xml이 requestEncoding 및 responseEncoding 속성을 설정했는지 확인합니다.
  
  그러나 이러한 액션으로 문제를 완전히 없앨 수는 없습니다.

인증

인증 메커니즘 및 예방책을 둘러싼 위협은 다음과 같습니다.

인증서 기반 인증은 크리티컬한 비즈니스 동작에 사용해야 합니다. 카탈로그 검색과 같이 크리티컬하지 않은 비즈니스 작업의 경우 암호 기반 인증을 선택하십시오.
네트워크 도청
- 네트워크 상에서 암호화되지 않은 패스워드 전달을 피합니다. SSL같은 암호화된 채널을 사용하면 브라우저 기반 인증에 필요한 패스워드를 암호화할 수 있습니다. 웹 서비스 인증의 경우 암호화 기술을 사용하여 패스워드를 보호합니다.
- 시스템이 데이터베이스같은 올바른 인증 메커니즘을 지원하지 않는 경우 Perimeter authentication을 사용하여 인증합니다. SAML 토큰 사용은 구체화된 인증 서비스를 사용하는 서로 다른 일련의 서비스에서 싱글 사인 온을 달성하는 기본적인 방법입니다.
사전(Dictionary) 공격

이것은 암호를 크랙하는 공격입니다. 예방책은 다음과 같습니다.
- 복잡하고, 정규 단어가 아니고, 치환 및 조합을 통해 크랙하기 어려운 암호를 사용합니다.
- 여러 번의 실패 시도에 대해 감사를 실행합니다.
쿠키 재생 공격

공격자가 인터셉팅 소프트웨어를 사용하여 쿠키를 훔쳐 가짜ID로 사용합니다. 이 문제의 대응책은 다음과 같습니다.
- 암호화된 채널을 사용할 수 없는 경우 Cookie time-out 메커니즘을 사용하여 재인증하도록 합니다.
- 로그아웃을 구현해야 합니다. 그러면 쿠키 재생 공격에 사용되는 윈도우를 줄일 수 있습니다.
SSL 채널과 관련된 쿠키는 인터셉트로부터 안전합니다.

권한 부여

권한 승격(Elevation of Privilege)

권한 승격은 악의적인 방법을 사용하여 정상적으로 할당된 권한 보다 많은 권한을 갖는 것입니다. 이러한 위협을 방지하려면 모든 리소스에 "최소한의 권한"을 사용해야 합니다. 위에서 언급한 리소스는 다음의 방법으로 보호될 수 있습니다.
- 데이터베이스 테이블
- - 시스템 테이블 및 애플리케이션 특정 테이블에 서로 다른 역할(Role)에 속하는 사용자 집합을 사용합니다.
  - AI 컨트롤을 사용하여 애플리케이션 특정 테이블에 액세스합니다. 애플리케이션 특정 테이블에 액세스가 허용된 특정 사용자에 대해 DBMS 어댑터를 구성해야 합니다. 이렇게 하려면 커넥터 아키텍처에 사용되는 "principal mapping" 테크닉이 필요합니다.
  - 여러 데이터베이스 사용자를 단일 커넥터 인스턴스가 주어진 여러 "애플리케이션 서버" 사용자에 매핑할 수 있습니다. 그러면 "최소한의 권한"을 주기가 쉬워집니다.
- 데이터베이스 풀
- - 데이터베이스에 액세스하기 위해 필요한 보안 역할(Role)만 커넥션 풀에 액세스하도록 허용해야 합니다. 이 풀은 역할(Role) 및 액세스 정책을 통해 보호해야 합니다. 자세한 내용은 http://edocs/wls/docs81/secwlres/index.html을 참조하십시오.
- 디스크 상의 설정 파일
- - SSL 채널을 통해서만 관리 콘솔을 액세스할 수 있도록 합니다.
  - 애플리케이션 특정 jar가 설정 파일에 액세스할 수 없도록 적절한 보안 정책을 설정합니다. 자세한 내용은 http://java.sun.com/j2se/1.3/docs/guide/security/permissions.html을 참조하십시오.
  - 설정 파일에 대한 쓰기 권한을 가진 "OS 사용자"가 관리 서버를 실행해야 합니다. 읽기 권한만 가진 사용자는 관리 서버(Managed Server)만 실행할 수 있습니다.
  - WebLogic 설치를 보호하기 위한 절차는 http://edocs/wls/docs81/lockdown/practices.html#1128006의 설명을 따르십시오.
- 키 저장소
- - 모든 weblogic 사용자로부터 보호해야 합니다. 이 파일은 중요한 파일이며 OS 수준 보호를 사용해야 합니다.
- WLI의 커넥터 리소스
- - 적절한 역할(Role)을 지정하여 커넥터를 보호합니다. 그렇지 않으면 시스템에 로그인한 모든 클라이언트(익명 로그인 포함)가 커넥터에 액세스할 수 있습니다. "최소한의 권한"을 사용하여 액세스 정책을 제어합니다.
- WLI 생성 EJB 및 WEBAPP 플랫폼 컴포넌트에 대한 JNDI 리소스
- - 이러한 리소스는 적절한 역할(Role)을 지정하여 보호합니다. 그렇지 않으면 시스템에 로그인한 모든 클라이언트(익명 로그인 포함)가 이러한 리소스에 액세스할 수 있습니다. "최소한의 권한"을 사용하여 액세스 정책을 제어합니다.
기밀 데이터 공개

승인되지 않은 사용자가 기밀 데이터를 볼 수 있는 경우 이러한 데이터가 공개될 수 있습니다. 이에 대한 대응책은 다음과 같습니다.
- 잠재적으로 개인 데이터를 노출시킬 수 있는 동작에 대한 액세스를 허용하기 전에 역할(Role) 확인이 필요합니다. 보안 관리에서 애플리케이션 관리를 분리시키는 것이 바람직합니다. 비즈니스 데이터의 보호 정책은 비즈니스 데이터에 관련된 개인 정보 보호 규정을 반영해야 합니다.
- 파일 시스템 수준 보호를 사용하여 승인되지 않은 액세스를 방지합니다.
- 암호화를 사용하여 중요한 데이터를 설정 파일 및 데이터베이스에 저장합니다.
데이터 변조

데이터 변조는 승인되지 않은 데이터 수정을 의미합니다. 이것을 방지하려면 다음을 따릅니다.
- 역할(Role) 기반 보안을 사용하여 데이터를 볼 수 있는 사용자와 데이터를 수정할 수 있는 사용자를 구별합니다.
- SSL 사용 통신 채널은 전송 중에 데이터 변조를 방지할 수 있습니다.
유인 공격

"유인 공격"은 공격자가 유인하는 속임수 또는 혼동을 유발하여 권한 또는 정보를 가진 트러스트된 코드를 공격자의 코드로 호출하도록 만드는 공격입니다.
- 애플리케이션 코드가 트러스트된 코드에서 콜백되도록 승인하기 전에 사용자 코드 서명 같은 적합한 인증을 사용하여 트러스트된 코드에 대한 액세스를 제한해야 합니다. 해당 애플리케이션이 요구하는 성능과 보안 수준은 서로 상반 관계에 있습니다.
- 보안 컨텍스트에서는 광범위한 코드 검색 프로세스가 필요합니다. 이를 통해 애플리케이션 코드에서 악의적 세그먼트를 확인할 수 있습니다.
- 관리 콘솔을 시작하는 시스템에 트러스트되지 않은 스파이 웨어 또는 다운로드된 코드가 있는지 확인하십시오. 복잡한 유인 공격은 관리 콘솔을 시작하는 브라우저를 제어하고 서버에 해로운 동작을 수행할 수 있습니다.

설정 관리

BEA 제품에 제공되는 설정 파일은 중요한 리소스이며 반드시 보호되어야 합니다. 이러한 파일에 대한 바람직하지 못한 읽기 및 쓰기 액세스에 대한 대응책은 다음과 같습니다.

이 문서에서 권한 부여 아래의 "디스크 상의 설정 파일" 단원을 참조하십시오.
WebLogic 툴을 사용하여 설정 파일의 패스워드를 암호화합니다.
workshop 툴을 사용하여 웹 서비스 정책 파일의 패스워드를 암호화합니다.

민감(Sensitive) 데이터
민감 데이터는 다양한 위협의 표적입니다. 이에 대한 몇 가지 대응책은 다음과 같습니다.

네트워크 도청
- 민감 데이터를 암호화합니다.
민감 데이터를 다루는 리소스에 "최소한의 권한"을 사용해야 합니다.

세션 관리

인증 부분을 참조하십시오.

암호화
http://e-docs.bea.com/wls/docs81/secintro/concepts.html#1091754 및 http://java.sun.com/products/jce/index.jsp를 참조하십시오.

예외 보고
내부적인 구현 세부 정보가 클라이언트에게 노출되지 않도록 방지하는 예방책은 다음과 같습니다.

애플리케이션의 코드 전체에 예외 처리를 사용합니다.
애플리케이션 경계까지 전파되도록 예외를 처리하고 로그합니다.
해를 끼치지 않는 일반 오류 메시지를 외부 클라이언트에 리턴합니다.

감사 및 로깅
주된 감사 및 로깅 관련 위협은 다음과 같습니다.

사용자가 동작 수행을 거부합니다. 대응책은 다음과 같습니다.
- WebLogic 로깅 서비스는 각 감사 문을 사용하여 사용자 ID 및 타임스탬프를 공격합니다. 이를 통해 진행 중인 모든 악의적인 동작을 탐지할 수 있습니다.
공격자가 흔적을 남기기 않고 탈출합니다. 대응책은 다음과 같습니다.
- 크리티컬한 애플리케이션 레벨 동작을 로그합니다.
- 감사 서비스를 사용하여 로그인 및 로그아웃 이벤트, 파일 시스템에 대한 액세스, 실패한 객체 액세스 시도를 감사합니다. 자세한 내용은 http://edocs/wls/docs81/dvspisec/aud.html#1169139를 참조하십시오.
- 의심스러운 동작을 탐지하기 위해 감사 파일에 대한 정기 분석 프로세스를 설정합니다.
공격자가 흔적을 숨깁니다. 대응책은 다음과 같습니다.
- 다양한 목적을 위해 감사 파일을 사용하는 사용자를 "최소한의 권한"을 사용하여 승인합니다. 이 문서에서 권한 부여의 "디스크 상의 설정 파일" 단원에서 설명한 것과 같은 유사한 조치를 취합니다.

다음 링크에서는 감사에 관해 자세히 설명합니다.
http://dev2dev.bea.com/products/wlserver/articles/Patrick_Rosenberg_02.html

파라미터 조작
파라미터 조작 공격은 클라이언트 및 웹 애플리케이션 사이에서 전달된 파라미터 데이터를 수정하는 것을 의미합니다. 파라미터 데이터에는 쿼리 문자열, 양식 필드, 쿠키 및 HTTP 헤더가 포함되어 있습니다.

서버에 입력되는 파라미터의 유효성을 검사합니다.
쿼리 문자열/양식 필드/Http 헤더 수정. 예방책은 다음과 같습니다.
- 파라미터를 암호화합니다.
- 파라미터에 기반하여 보안 결정 또는 애플리케이션 흐름을 결정하지 않도록 합니다.
쿠키 조작. 대응책은 다음과 같습니다.
- 항상 암호화된 쿠키를 사용합니다. 악성 소프트웨어가 클라이언트 컴퓨터에 상주할 수 있으므로 클라이언트 쿠키를 업데이트합니다.

위협 확인

기본적인 방법론을 사용하여 다음과 같은 유형의 위협을 확인할 수 있습니다.

네트워크 위협

다음과 같은 원인이 있을 수 있습니다.

정보 수집
스니핑(Sniffing)
스푸핑
세션 하이잭
서비스 거부(DoS)

호스트 위협

다음과 같은 원인이 있을 수 있습니다.

승인되지 않은 익명의 액세스 허용.
바이러스, 트로이 목마, 웜 등의 최신 패치 사용 안 함.

애플리케이션 위협

자세한 내용은 보안 프로파일 단원을 참조하십시오.

공격 트리 프로세스를 사용하여 위협을 보다 여러 방면에서 분석합니다.

위협 정보에 기반한 보안 강화

다음은 위협 정보를 사용하여 배포된 애플리케이션의 보안을 향상시킬 수 있는 방법을 설명합니다.

주어진 시스템에 생성된 보안 프로파일의 컨텍스트에서 위협의 가능성을 확인합니다.
위협의 우선 순위를 지정하기 위해 정규 위험 분석을 수행합니다.
발견 사례를 문서로 요약하고 애플리케이션을 구축하는 개발 팀과 이러한 정보를 공유합니다.
보안 프로파일 속성은 코드를 변경하지 않고 구성이 가능하기 때문에 애플리케이션 코드와 보안 코드를 분리합니다.
파생된 보안 프로파일의 컨텍스트에 새로운 보안 취약성 보고 및 해당 패치에 관한 최신 정보를 유지합니다.

요약

공격의 위험을 줄일 수는 있지만 모든 위협을 없애는 것은 불가능합니다. 위협의 존재를 인정하고 그에 따른 위험을 관리하는 것이 중요합니다. 위협 모델링은 상호 작용적인 프로세스이며 위험 관리에 도움을 줄 수 있습니다. 다음과 같은 대응책이 있습니다.

보안망에서 가장 취약한 링크를 보호합니다.
다중 레이어로 보호를 사용합니다.
최소한의 권한을 할당합니다.
공격 노출 영역을 줄입니다.
단순성을 유지합니다.

부록: 정의

위협
불필요한 결과를 만드는 잠재적 이벤트.

취약성
설계 문제 또는 버그 등과 같은 시스템의 약점.

공격
취약성을 악용하여 자산 위협.

감사의 말씀

이 문서를 검토하느라 시간을 내 주신 Paul Patrick, Neil Smithline 및 Liz Lynch에게 진심으로 감사드립니다

시소당

WebLogic Platform 8.1을 사용한 보안 소개