OJT [3]

[ 4 주차 ] ISVA 아키텍쳐 및 인증 프로세스 + ISVA 액세스 제어 관리 (ACL / POP)

 

1. ISVA 내부에서 사용자가 요청한 주소를 인식 하고 해당 되는 IP 주소를 찾아 사용자에게 응답 하는 과정 정리

 

 

1) 사용자는 SSO (Single Sign-On) 기능이 있는 서비스를 이용하기 위해 URL에 도메인명을 입력 한다.

* 도메인명 : www.example.com

 

2) 해당 도메인명과 도메인명에 해당 하는 IP 주소가, Hosts 파일 또는 DNS 서버에 등록 되어 있다고 가정.

 

사용자가 입력한 도메인명은 SSO 기능을 이용 하기 위한 ISVA Appliance 내부 WebSEAL Server의 IP 주소에 해당 하는 도메인명이 된다.

 

3) WebSEAL Server에 사용자의 인증 정보가 없는 경우, 인증 및 권한 부여를 위해 302 Redirect가 진행 된다.

 

4) 사용자는 본인의 자격을 증명하기 위해서 인증 정보를 제출 한다.

 

5) WebSEAL Server는 사용자의 인증 정보를 LDAP (ISVD) 를 거치고 성공적으로 인증을 통과하면 사용자의 인증 정보를 인증 세션에 담게 된다.

이 인증 정보를 다시 Policy Server로 전달하고 사용자에 대한 인가를 수행하게 된다.

 

만약, 인증 정보가 애초에 유효하지 않았으면 다시 인증 정보를 제출해야할 것이다.

 

6) 인증 정보가 유효했고, 인가도 모두 처리됬으면, WebSEAL Server의 Virtual Junction에 매핑된 BackEnd Server으로 사용자의 요청이 전달 된다.

 

이때, 처음에 사용자가 URL에 입력한 도메인명은 WebSEAL Server의 도메인명이지만, 실질적으로 Virtual Junction의 Host Name (도메인명) 과 완전히 일치 해야 한다.

 

7) BackEnd Server는 사용자의 요청에 대한 관련된 여러 로직을 수행한 후, 사용자가 해당 서비스를 이용하기 위해 필요한 여러 관련된 응답 데이터를 WebSEAL Server로 보낸다.

 

8) WebSEAL Server는 BackEnd Server로 부터 받은 응답 데이터를 포함 해서, WebSEAL Server에서 생성한 사용자의 인증 세션의 Session_ID (세션 키 값) 을 포함한 Cookie를 웹 브라우저로 전달 한다.

 

9) 사용자는 WebSEAL Server로 부터 응답 데이터를 받고 페이지를 랜더링 하고, Cookie는 브라우저에 저장 및 관리 하게 된다.

 

10) 이후, 사용자가 다시 서버로 요청을 하는 경우, 인증 세션의 Session_ID 값이 포함된 Cookie를 함께 보내게 된다. 이 쿠키를 통해 WebSEAL Server는 일치하는 사용자의 인증 세션을 찾고, 적절한 응답 처리를 할 수 있게 된다. 

 

따라서, 인증세션 및 세션 쿠키가 만료되기 전까지는 재 인증이 필요 없게 된다.

인증 정보가 WebSEAL Server에 존재하기 때문에, 사용자 인증 정보를 Policy Server로 보내고, 인가에 대한 요청 및 응답만 효율적으로 이루어진다.

 

2. ISVA에서 Policy Server을 remote로 구축했을 때랑 local로 구축했을 때의 차이점 및 개념 정리

 

 

* local : ISVA 서버와 동일한 서버에서 Policy Server을 구축 하는 것을 의미.

* remote : 메인의 ISVA 서버에, 다른 ISVA 서버의 LMI을 통해 Policy Server을 구축 하고 연결 시켜주는 것을 의미.

 

remote로 구성 했을 경우 :

 

장점 : 

 

ISVA 서버와 Policy Server는 각각의 다른 서버이기 때문에 다수의 요청에도 서버의 부하가 발생 하지 않고 효율적으로 응답할 수 있다는 장점을 갖게 된다.

(* 메인의 ISVA 서버에, 외부 에서 구축한 Policy Server을 Runtime Component 설정을 통해 구현 한다)

 

단점 :

 

ISVA 서버와 Policy Server을 각각 따로 구성 하기 때문에 서버 유지 비용이 배로 증가 하게 된다. 뿐만 아니라, 서버를 별도로 구성 하기 때문에 설정 및 운영 관리가 어려워진다는 단점이 발생 한다.

 

 

 

local로 구성 했을 경우 :

 

장점 :

 

ISVA 서버와 동일한 서버에 Policy Server도 같이 구축 하기 때문에, 서버 유지 비용이 절감 된다. 뿐만 아니라, 하나의 단일 서버로 관리할 수 있기 때문에 설정 및 운영 관리가 용이해지는 장점을 갖게 된다.

 

단점 :

 

ISVA와 Policy Server을 동일한 서버에 같이 구축 했기 때문에, 한 개의 단일 서버 내부에서 여러 개의 기능이 동작 된다. 따라서, ISVA 내부의 WebSEAL 서버 또는 Policy Server 등 한 곳의 서버에 장애가 발생 하게 되면 모든 서버가 마비된다는 단점이 발생 한다.

 

 

 

* [ 참고 ]

 

ISVA (IBM Security Verify Access) 개념 (tistory.com)

ISVA (IBM Security Verify Access) 개념

 

3. ISVA가 보호하는 리소스란 무엇인가 ?

 

 

* [ 참고 ]

 

4. WebSEAL Server가 Cookie를 인식 하는 방법과 인증 데이터를 확인 하는 방법

 

 

WebSEAL Server가 Cookie를 사용 하는 이유 :

>> 세션 상태를 유지 하기 위해서 클라이언트와 서버는 세션 정보를 보관 하기 위해 Cookie를 활용.

 

1) 처음 사용자가 WebSEAL Server로 특정 요청을 보낸다.

 

2-1) 일련의 과정이 끝나면, WebSEAL Server에서 사용자에게 응답 데이터를 보내주게 된다.

 

2-2) 이때, WebSEAL Server에서 생성했던 사용자의 정보가 담긴 인증 세션의 식별자인 Session_ID 값을 Cookie에 포함시킨다.

 

2-3) 이렇게 Session_ID 값을 담은 Cookie를 세션 쿠키라고 한다.

 

2-4) 최종적으로 WebSEAL Server는 헤더에 세션 쿠키를 담아 사용자에게 응답 데이터를 보내게 된다.

 

3) 사용자는 WebSEAL Server에게 세션 쿠키가 포함된 응답 데이터를 받고, 브라우저에 세션 쿠키를 저장 한다.

 

4) 이후, 사용자가 다시 WebSEAL Server로 요청을 보낼 때, 요청 데이터의 헤더에 세션 쿠키를 포함 하고 보낸다.

 

5) WebSEAL Server에서는 사용자의 요청을 받고, HTTP 요청 데이터의 헤더에 들어 있는 세션 쿠키를 읽게 된다.

 

6) 세션 쿠키 내부의 Session_ID 값에 일치 하는 인증 세션을 찾고, 최종적으로 사용자의 인증 데이터를 확인 하게 된다.

 

 

 

[ 참고 ]

 

세션 쿠키에는 인증 세션의 키 값만 포함 되어 있다.

 

세션 쿠키는 브라우저의 메모리에 저장 한다.

 

세션 쿠키는 당연히 수명이 존재 한다.

 

세션 쿠키를 서버에서 생성할 때 사용자의 요청 브라우저 호스트 (도메인) 를 파악 한다.

오직 동일한 호스트로만 쿠키를 주고받을 수 있다.

 

사용자는 세션 쿠키 생성을 거부할 수 있다.

하지만 이런 경우 사용자가 매 번 새로운 요청을 하고 로그인에 성공해서 인증될 때마다,

서버는 매 번 새로운 세션을 생성 하게 된다.

이러한 재 인증 및 세션 생성은 서버의 성능을 저하시킬 수 있게 된다.

 

 

 

* [ 참고 ]

 

Session cookies concepts - IBM Documentation

Session cookies concepts

 

Conditions for using session cookies - IBM Documentation

Conditions for using session cookies

 

5. Object Space의 의미 및 각각의 요소들의 개념

 

 

ISVA에서는 정책을 관리 하기 위해서 3 가지 개념을 사용 한다.

 

1) Domain

2) Object Space

3) Object

 

Domain은 쉽게 말하면 정책 관리 영역을 의미 한다.

 

Object Space와 Object는 이러한 정책 관리 영역에 속하는 자원을 관리 하기 위한 개념이라고 보면 된다.

 

ISVA에서는 자원 (리소스) 을 트리 구조로 관리 한다.

 

이때, 사용되는 논리적인 개념 요소가 Object Space와 Object 이다.

 

예)

 

 

 

Object는 2개의 타입으로 구성 되어 있다.

 

1) Resource Object : 이미지 파일, 웹 페이지, 로그 등과 같은 실제적인 물리적 리소스에 대한 논리적인 표현 요소.

 

2) Container Object :리소스 (자원) 객체를 계층적으로 그룹화하는 구조적인 구성 요소.

 

예) /Management, /WebSEAL, /User, ..

 

 

 

Object Space는 Object들의 묶음이라고 생각 하면 된다.

 

 

 

참고 :

 

 

위와 같이 LMI의 Policy Administration 메뉴에서 Domain 설정이 가능 하다.

 

 

 Object Space도 확인할 수 있다.

 

 

위의 이미지는 전체 객체를 보여 주는 것이다. ISVA가 설치될 때 작성 되는 공간 이다. /Management

 

 

이런식으로 확인이 가능 하다.

 

 

 

* [ 참고 ]

 

Protected object space - IBM Documentation

Protected object space

 

ISVA (IBM Security Verify Access) 개념 (tistory.com)

ISVA (IBM Security Verify Access) 개념

 

6. Object Space에서 favicon과 pics가 있는 이유는 무엇인가 ?

 

 

 

 

7. HTTP 동작 과정 설명

 

 

HTTP (HyperText Transfer Protocol) 은 서로 다른 시스템들 간에 통신을 주고받게 하는 프로토콜 이다.

 

오늘날 데이터 통신에 가장 많이 사용 되는 표준 프로토콜 이다.

 

[ HTTP 동작 과정 ]

 

1) 클라이언트의 요청

2) DNS (Domain Name System) 를 통한 조회

3) TCP 연결 설정

4) 서버 접속 및 요청 전송

5) 서버의 응답

6) 응답을 클라이언트에게 전송

7) TCP 연결 종료

 

크게 위의 7가지의 과정으로 나눌 수 있다. 아래에서 자세하게 정리해보도록 하자.

 

1) 클라이언트의 요청

 

사용자가 웹 브라우저를 통해 특정 웹페이지에 접속을 요청 한다.

예를들어, 사용자가 브라우저에 http://www.example.com/index.html 을 입력 하면,

브라우저는 이것을 HTTP 프로토콜 요청으로 변환 하게 된다.

 

2) DNS를 통한 조회

 

브라우저는 도메인 명 (www.example.com) 에 매핑 되어 있는 IP 주소를 찾기 위해서 DNS 서버에 접속 한다.

 

사실 DNS 서버에 접속 하기 전에, 로컬 DNS 캐시를 확인 하고, 로컬 호스트 파일도 확인 한다.

 

이렇게 DNS 조회를 통해 서버의 IP 주소를 얻게 되면 다음 과정을 수행 하게 된다.

 

TCP 연결 설정이고 뭐고, 서버와 연결을 하기 전에 무조건 서버의 IP 주소를 얻고 나서 이후의 과정 이다.

 

3) TCP 연결 설정

 

브라우저는 DNS 조회를 통해 얻은 서버의 IP 주소로 TCP 연결을 설정 한다.

 

TCP 연결을 하기 위한 포트는 일반적으로 정해져있다. HTTP는 80번 포트, HTTPS는 443 포트 이다.

 

4) 서버 접속 및 요청 전송

 

TCP 연결이 설정 되고 나서 이후에 브라우저는 HTTP 요청 메세지를 생성해서 서버로 전송 하게 된다.

 

이때 HTTP 요청 메세지는 브라우저에서 생성 되는 개념 이다.

 

HTTP 요청 메세지는 start-line, 헤더 필드 (요청시 부가 정보), CRLF (개행), message-body의 구성을 가지게 된다.

 

start-line에는 어떤 방식의 요청인지에 대한 메서드 정보가 들어 있다. (GET / POST / ..)

 

5) 서버의 응답

 

서버는 사용자에게 받은 HTTP 요청을 기반으로 리소스 또는 페이지를 찾고 이를 포함한 HTTP 응답 메세지를 생성 한다.

 

HTTP 응답 메세지는 start-line, 헤더 필드 (응답시 부가 정보), CRLF, message-body의 구성을 가지게 된다.

 

start-line에는 상태 코드 (200 OK, 404 Not Found, .. 등등) 의 정보가 들어 있다.

 

6) 응답의 전송

 

서버는 5)에서 생성한 HTTP 응답 메세지를 브라우저로 전송 한다.

 

7) TCP 연결 종료

 

최종적으로 HTTP 응답 메세지가 전송 되고 나면 TCP 연결이 종료 된다.

 

전송된 응답 메세지를 기반으로 브라우저는 응답 메세지를 해석 하고, 웹 페이지를 랜더링 하게 된다.

 

 

 

위의 과정은 기본적인 HTTP 요청 및 응답의 흐름 과정 이다.

 

실제 동작은 및 각각의 단계는 더 복잡하지만 전체적인 흐름은 위와 같다고 보면 된다.

 

이러한 일련의 과정은 순차적으로 진행되는 것을 알 수 있다.

 

DNS 조회 >> TCP 연결 설정 >> HTTP 요청 메세지  >> HTTP 응답 메세지  >> TCP 연결 종료

 

 

 

* [ 참고 ]

 

DNS (Domain Name System) (tistory.com)

DNS (Domain Name System)

 

HTTP vs HTTPS [1] & SSL (tistory.com)

HTTP vs HTTPS [1] & SSL

 

https://hwanii96.tistory.com/536

HTTP vs HTTPS [2] & SSL

 

8. DNS (Domain Name System) 란 무엇인가 ?

 

 

DNS는 도메인명을 IP Address로 변환해주는 시스템을 의미 한다.

 

즉, 클라이언트가 URL에 등록된 도메인명을 입력 하면 그 도메인명에 매핑 되는 IP 주소를 찾아 주는 시스템 이다.

 

예)

www.naver.com  을 223.130.200.104로 변환.

 

* TLD (Top-Level Domain) 는 com에 해당 한다.

* naver가 (중간) 도메인에 해당 한다.

* www는 서브 도메인에 해당 한다. (최근에는 www는 생략 하고 나머지 도메인명만 입력 해도 된다)

* www.naver.com  을 모두 통틀어서 도메인명 (Domain Name) 이라고 지칭 한다.

 

 

 

* [ 참고 ]

 

DNS (Domain Name System) (tistory.com)

DNS (Domain Name System)

 

9. Cookie와 Session에는 어떤 데이터가 담겨 있을까 ?

 

 

Cookie의 구성 요소 :

 

1) 이름 (Name) : 쿠키의 식별을 위한 이름

1_2) 세션 식별자 (Session_ID) : 서버로 쿠키를 전송할 때, 사용자의 세션을 식별 하기 위한 고유한 

2) 값 (Value) : 쿠키와 연결된 데이터

3) 도메인 (Domain) : 쿠키를 전송할 도메인

4) 경로 (Path) : 쿠키의 적용 경로

5) 만료 날짜 (Expires) : 쿠키의 유효 기간

6) 보안 (Secure) : HTTPS 프로토콜 통신일 때만 쿠키를 전송할건지에 대한 요소

7) HttpOnly : 스크립트를 통한 접근을 방지 하고 쿠키를 보호하는 요소

 

예)

 

user_id=hwanii; session_id=ABC123XYZ789; Domain=.example.com; Path=/user; Expires=Fri, 22 Dec 2023 23:59:59 GMT; Secure; HttpOnly 

 

* 쿠키 데이터는 세미콜론 ( ; ) 을 통해 각각의 쿠키를 구분한다.  ; 으로 구분된 문자열은 각각의 개별적인 쿠키 이다.

 

* 중간 도메인인 example 앞에 . 을 붙힘으로써, example 이라는 도메인의 하위 도메인 (서브 도메인) 에 대한 모든 요청에서도 쿠키를 사용할 수 있음을 의미 한다. 이는 쿠키의 공유성이 강화됨을 의미 한다. 로그인 정보 및 세션을 여러 서브 도메인에서 공유해야 하는 경우에 유용하다고 볼 수 있다.

 

Session의 구성 요소 :

 

1) 세션 식별자 (Session ID) : 클라이언트와 서버가 상호 작용할 때, 사용자를 식별 하기 위한 고유한 값

2) 세션 데이터 (Session Data) : 서버에 저장 되는 사용자의 데이터 이다

 

예)

 

세션 식별자 (Session_ID) : 고유한 세션을 식별하는 데 사용되는 문자열 또는 숫자 조합

>> ABC123XYZ789

 

세션 데이터 (Seesion Data) : 서버에서 사용되는 사용자에 관련된 데이터

>> 사용자 정보 / 장바구니 내역 / 로그인 상태 / .. 등등

 

 

 

* [ 참고 ]

 

https://hwanii96.tistory.com/544

OJT [1]

 

세션 (Session) & 쿠키 (Cookie) (tistory.com)

세션 (Session) & 쿠키 (Cookie)

 

10. ISVA에서 Session은 어떻게 관리 되는가 ?

 

 

WebSEAL은 사용자에 관련된 세션에 대한 정보를 저장 한다.

 

이때, 각 사용자 세션은 세션 정보가 담긴 캐시 테이블의 구조를 갖게 된다.

 

 

Session Key : WebSEAL Session ID 이다. 이것은 각각의 사용자가 생성한 요청을 의미 한다.

즉, Session Key는 특정 사용자를 구별짓는 식별자 이다.

 

Cache Data : Cache Data에는 특정 사용자에 대한 여러가지 정보가 저장 된다.

여기서 제일 중요한 것은 사용자 자격 증명 이다.

자격증명은 사용자가 보호된 자원을 요청할 때마다 필요하게 된다.

 

* 사용자 자격 증명 데이터 : 1) 사용자 이름 2) 그룹 구성원 자격 3) etc .. 

 

Time-Stamps : Time-Stamps 캐시 항목은 세션 수명에 대한 정보를 의미 한다.

 

 

 

[ 추가 내용 ]

 

WebSEAL의 Session Cache는 사용자에 대한 관련 정보를 저장 한다고 했다.

 

인증된 사용자의 정보도 저장 하고, 인증되지 않은 사용자의 정보도 저장 한다.

 

그리고 WebSEAL은 사용자의 정보를 담은 Session뿐만 아니라, SSL Session Cache도 저장 한다.

 

SSL Session Cache는 SSL Session을 유지 관리하는데 사용 된다.

 

이 SSL Session은 다른말로 보안 세션 이라고도 불리며, 보안 세션은 SSL/TLS 핸드셰이크가 완료되고 나면 통신의 보안을 유지하고 관리하는 데 사용 되는 개념의 세션 이다.

 

핸드셰이크 과정에서 생성된 세션 키를 사용 해서 데이터를 암호화 하고 복호화할 수 있다.

이를 통해 데이터가 안전하게 통신될 수 있다.

 

그밖에 인증서를 통한 클라이언트와 서버간의 상호 신원 확인도 확인된다.

 

뿐만아니라, 보안 세션에는 사용 중인 암호 알고리즘, 세션 키, 인증서 등과 같은 보안 정보가 저장 된다.

 

세션은 일정 기간 동안만 유지 된다.

기존의 세션이 만료되기 전까지는 동일한 세션을 사용 해서 클라이언트와 서버 간의 통신에서 계속 해서 사용된다.

 

 

 

 

 [ 추가 내용 2 ]

 

 

Client는 WebSEAL Server와 HTTP 프로토콜로 요청 및 응답하는 과정에서 WebSEAL Server는 Client에 관련된 Session을 생성 하고, Session Cache를 테이블의 구조로 저장 한다.

 

또, WebSEAL의 Junction으로 매핑된 Application Server와의 별도의 User Session을 생성 해서 관리할 수 있다.

 

이것은 Client와 Virtual Junction으로 매핑된 BackEnd Server 간의 세션 상태를 의미하는 Session 이다.

 

User Session ID는 인증된 사용자에 대한 특정 Session을 고유하게 식별하고 사용자의 자격 증명 정보의 일부로 사용 된다.

 

 

 

* [ 참고 ]

 

WebSEAL 세션 캐시 구조 - IBM Documentation

WebSEAL session cache structure

 

 

Session cache configuration overview - IBM Documentation

Session cache configuration overview

 

사용자 세션 관리 개념 - IBM Documentation

User session management concepts

 

[ SVA ] Session과 Distributed Session Cache (velog.io)

[ SVA ] Session과 Distributed Session Cache