OJT [1]

[ 1 주차 ] SSO, ISVA 용어 숙지 및 기본 개념 이해 + ISVA 기본 구성 요소 이해

 

1. SSO란 무엇 인가 ? (정의)

 

 

SSO는 Single Sign-On의 약어로 한 번의 로그인으로 다양한 서비스 및 응용 프로그램에 접근할 수 있는 인증 기술 이다.

 

SSO 시스템의 핵심은 사용자가 한 번 로그인에 성공 하면 다른 서비스에서 다시 로그인을 할 필요 없이 인증 정보를 공유 하고 재사용하여 접근할 수 있게 하는 것이다.

 

SSO는 다양한 프로토콜 및 기술을 사용해서 구현될 수 있다. 주로 국제 표준 프로토콜인 OAuth, OIDC, SAML이 사용 된다.

 

위와 같은 프로토콜을 사용 해서 서로 다른 시스템 간에 사용자 정보를 안전하게 전달 하고 인증을 수행 하게 된다.

 

* OAuth, OIDC, SAML : 국제 표준 인증 프로토콜.

* OAuth : Open Authorization.

* OIDC : OpenID Connect.

* SAML : Security Assertion Markup Language.

 

* [ 참고 ]

 

SSO (Single Sign-On) 란 ? (tistory.com)

SSO (Single Sign-On) 란 ?

 

* [ 추가 내용 ]

 

OAuth : Open Authorization.

 

[ OAuth 개요 ]

 

위에서 국제 표준 인증 프로토콜 이라고 말했지만, 사실상 단어 뜻 그대 Authorization이기 때문에 주된 목적 인가 (권한) 부여에 있다. 사용자가 아이디 및 비밀번호를 제공 하지 않아도 접근 권한을 얻을 수 있도록 하기 때문에 권한 부여 국제 표준 프로토콜 이라고 해도 무방 하다.

 

OAuth는 사용자가 이용하려고 하는 서비스의 외부 서비스 (서드 파티 애플리케이션) 와의 연동으로 별도의 회원 가입 없이 로그인을 할 수 있도록 한다. 이것이 OAuth 이다.

 

예시)

 

 

[ OAuth가 생겨나게 된 배경 ]

 

수많은 웹사이트가 생겨나면서 로그인을 해야 하는 상황이 많아지게 된다. 이는 사용자의 개인정보를 여러 곳에 입력 해야 하는 것을 의미 한다. 개인 정보를 여러 곳에 입력 하면 보안에 취약해진다. 이로 인해 Twitter의 주도로 인증 및 인가 (권한) 을 부여 하는 OAuth 1.0을 개발 하게 되었다.

 

[ OAuth의 장점 ]

 

1) 클릭 한 번으로 간편하게 로그인이 가능 하다.

 

2) 아이디 및 비밀번호를 직접 입력 하는 것이 아니라, 서드 파티 어플리케이션 (서비스)의 정보를 연동 하고, 인증을 하는 방식이므로 개인 정보를 직접 입력 하는 것 보다 상대적으로 보안에 안전하게 된다.

 

3) 연동 되는 외부 서비스에서 제공 하는 기능을 간편 하게 사용할 수 있다.

 

 

 

* [ 참고 ]

 

OAuth (Open Authorization) (tistory.com)

OAuth (Open Authorization)

 

 

2. 인증과 인가란 무엇 인가 ?

 

 

인증과 인가는 보안과 관련된 두 가지 핵심 개념 이다.

 

[ 인증 ]

 

정의 : 사용자가 로그인할 때, 서버는 사용자가 제공한 자격 증명을 검증해서 사용자가 누구인지 확인 한다.

 

* 자격 증명 : 아이디 및 비밀번호, 생체 인식 정보 (바이오 인증), 토큰, .. 등

 

목적 : 인증의 주 목적은 서비스에 접근하려고 하는 사용자가 올바른 자격 증명을 제대로 제공했는지를 확인 하고, 무단 접근을 방지 한다.

 

[ 인가 ]

 

정의 : 인증된 사용자에게 특정 자원 및 서비스에 대한 접근 권한을 부여 하는 과정 이다.

 

목적 : 인가의 주 목적은 인증에 성공한 사용자에 대한 권한을 관리 해서 보안을 강화 하고 무결성을 유지 한다.

* 인증 : Authentication

* 인가 : Authorization

 

* [ 참고 ]

 

인증 (Authentication) & 인가 (Authorization) (tistory.com)

인증 (Authentication) & 인가 (Authorization)

 

3. ISVA에서 쿠키와 세션을 사용 하는 이유

 

 

쿠키와 세션은 웹 프로그래밍에서 사용 되는 기술 이다. 클라이언트와 서버간의 상태 정보를 유지 및 관리를 위해 사용 한다.

 

세션 (Session)

 

[ 정의 ]

서버 측에 클라이언트와 서버 간의 상태를 유지 하기 위한 사용자 정보를 저장 하는 방식 이다.

 

[ 특징 ]

 

1) 세션은 오로지 서버에 저장 된다. 세션을 식별할 수 있는 세션 식별자 (쿠키) 는 클라이언트에 저장 된다.

 

2) 클라이언트가 웹 브라우저를 종료 하면 세션은 종료 된다.

 

3) 주로 사용자의 로그인 상태 유지, 사용자의 장바구니 정보, .. 등에 활용 된다.

 

[ 동작 방식 ]

클라이언트가 인증에 성공 하면 서버에서 해당 클라이언트의 상태 정보를 저장 하게 된다.

 

 

 

쿠키 (Cookie)

 

[ 정의 ]

클라이언트가 사용 하고 있는 웹 브라우저의 쿠키 저장소에 저장 되는 작은 데이터 조각 이다. 특정 정보를 담기 위해 서버는 쿠키를 생성 하고 클라이언트에게 전달 한다. 클라이언트는 쿠키를 저장 하고 필요할 때 사용 한다.

 

[ 특징 ]

 

1) 클라이언트에 저장 되기 때문에 브라우저를 종료 해도 유지될 수 있다. (쿠키의 영속성)

 

2) 서버로 전송 되어야 하는 모든 요청마다 요청 헤더에 쿠키가 함께 전송 된다.

 

3) 쿠키는 주로 사용자 식별, 사용자 설정, 사용자 경험 개선 등에 활용 된다.

 

4) HTTP 프로토콜은 Stateless의 특징을 가지므로, 상태 정보를 저장 할 수 없다. 즉, 연결이 끊어지면 이전 통신의 정보를 전혀 알 수 없다. 따라서 쿠키를 사용 해서 HTTP의 Conectionless와 Stateless의 특징을 보완할 수 있다.

 

[ 동작 방식 ]

클라이언트가 서비스에 로그인을 하고 인증에 성공 하면, 서버에는 클라이언트의 상태 정보가 담긴 Session 생성 및 저장을 하고, 서버는 Cookie를 생성 해서 응답 헤더에 Cookie를 포함 시켜서 클라이언트에게 보내준다. Cookie는 클라이언트의 브라우저에 저장 되고, 이 후 클라이언트가 서비스를 다시 이용할 경우 해당 Cookie를 요청 헤더에 포함 시켜서 서버로 전송 하고 사용자의 인증 정보를 확인하기 위한 세션 식별자의 역할 등으로 사용 된다.

예)

 

Response Header (응답 헤더) :

 

HTTP/1.1 200 OK
Set-Cookie: username=hwanii; expires=Wed, 21 Dec 2023 12:00:00 GMT; path=/; domain=.example.com
Content-Type: text/html

<!-- 응답 본문 -->

 

Set-Cookie 라는 헤더는 클라이언트에게 username이라는 쿠키를 설정하도록 한다.

따라서 이 쿠키는 hwanii 라는 값을 가지며, .example.com 도메인의 모든 경로에 적용 된다.

뿐만 아니라, 쿠키의 만료 날짜 까지 정해 진다.

 

 

 

Request Header (요청 헤더) :

 

GET /some-page HTTP/1.1
Host: www.example.com
Cookie: username=hwanii; sessionid=testSession123

 

Cookie 헤더는 클라이언트가 서버에게 username과 sessionid 라는 두 개의 쿠키 값을 전달 하게 된다.

 

사용자가 서비스에 접속 하게 되면 서버는 세션을 생성 한다. 이 세션을 식별 하기 위해서 sessionid라는 고유한 식별자가 있고, 서버는 이 sessionid를 쿠키에 담아서 클라이언트에게 보내 주게 된다. 그렇기 때문에 클라이언트가 다시 서버로 요청을 보낼 때 sessionid 값을 보내서 일치 하는 세션을 찾게 된다.

 

* [ 참고 ]

 

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

세션 (Session) & 쿠키 (Cookie)

 

4. Proxy Server의 개념과 Forward Proxy와 Reverse Proxy의 사용 목적

 

 

프록시 서버는 클라이언트와 서버 간에 중간에서 동작 하는 중계 서버 이다. 클라이언트의 요청을 받아 서버로 전달 하고, 서버로부터 받은 응답을 클라이언트에게 전송 하는 역할을 한다. 프록시 서버는 다양한 목적으로 사용되지만, 주로 네트워크 보안, 웹 캐싱, 익명성 보호 등에 활용 된다.

 

* 보안 (Security) :

클라이언트와 서버가 직접 통신 하지 않고 중간에서 중계 되기 때문에 서버에 직접적으로 노출되지 않는다. 이를 통해 서버의 실제 IP 주소를 감추고 클라이언트의 요청을 필터링 하고 보안 검사를 수행할 수 있다.

(서버 관점)

 

* 캐싱 (Caching) :

프록시 서버는 이전에 받은 응답을 저장 한다. 동일한 요청이 들어올 경우 캐시된 응답을 반환 하게 된다. 이를 통해 네트워크 대역폭을 절약하고 응답 시간을 단축시킬 수 있게 된다. 특히 정적 컨텐츠의 경우 캐싱을 통해 성능을 향상시킬 수 있다.

 

* 익명성 (Anonymity) :

프록시 서버를 통해 클라이언트가 서버에 접근 하면, 클라이언트는 실제 IP 주소 대신 프록시 서버의 IP 주소가 서버에 전달 된다. 이를 통해 사용자의 익명성을 유지 하고 개인 정보를 보호할 수 있다.

(사용자 관점)

 

 

 

[ Forward Proxy ]

 

클라이언트 관점 이다.

 

클라이언트 >> 전방 프록시 서버 >> 인터넷 >> 서버 의 흐름 이다.

 

클라이언트의 요청이 전방 프록시 서버를 통해 서버로 가지므로, 서버는 클라이언트의 IP 주소 등의 정보를 알 수 없게 된다. 이를 통해, 클라이언트의 익명성 유지에 유리해진다.

 

 

 

 

[ Reverse Proxy ]

 

서버 관점 이다.

 

클라이언트 >> 인터넷 >> 후방 프록시 서버 >> 서버 의 흐름 이다.

 

클라이언트의 요청은 인터넷으로 가지게 되고, 인터넷에서 클라이언트의 요청이 후방 프록시 서버로 가게 된다. 후방 프록시 서버는 적절한 서버로 요청을 전송 하게 된다. 이를 통해, 클라이언트는 서버의 IP 주소 등의 정보를 알 수 없게 된다. 따라서 서버의 보안 향상에 유리해진다.

 

 

 

 

* [ 참고 ]

 

Proxy Server (프록시 서버) (tistory.com)

Proxy Server (프록시 서버)

 

5. Linux OS를 구축할 때 DHCP와 Static의 차이점과 사용 목적.

 

 

리눅스 운영체제를 구축할 때, 네트워크 설정에서 DHCP와 Static 할당 방식을 선택할 수 있다.

 

* DHCP : Dynamic Host Configuration Protocol : 동적 할당 방식

* Static : Static IP Address : 정적 할당 방식

 

일반적으로 리눅스 운영체제를 구축 한 후, 네트워크 설정은 고정 IP를 할당 하는 정적 할당 방식을 사용 한다.

사실 리눅스 뿐만 아니라 대부분의 경우 서버를 다시 시작해도 IP 주소가 변경 되지 않도록 고정 IP 주소를 사용 한다.

 

서버의 IP 주소는 상식적으로 안정적이고 예측 가능 해야 하기 때문 이다.

특별한 경우가 아니라면 서버의 IP 주소는 변경 되지 않도록 설정 한다.

 

하지만, 가끔은 DHCP 방식으로 서버에 동적 IP 주소를 할당 하는 경우가 존재 한다.

 

 

 

[ DHCP ]

 

동작 원리 :

 

클라이언트가 네트워크에 연결되면 DHCP 서버에서 IP 주소와 서브넷 마스크, 기본 게이트웨이, DNS 서버 등의 네트워크 설정 정보를 동적으로 할당 받게 된다.

 

장점 :

 

1) 네트워크 관리의 용이.

 

2) 자동으로 IP 주소가 할당되므로 수동 구성의 번거로움이 사라진다. 

 

3) IP 주소 충돌을 방지할 수 있다.

 

사용 목적 :

 

1) 대규모 네트워크 환경에서 효과적으로 IP 주소를 관리하고 유동적으로 대응 해야 하는 경우.

 

2) 네트워크에서 장치가 자주 변경 되는 경우.

 

 

 

[ Static ]

 

동작 원리 :

 

(네트워크) 관리자가 수동으로 IP 주소와 서브넷 마스크, 게이트웨이, DNS 서버 등을 설정 한다.

 

장점 :

 

1) 항상 동일한 IP 주소를 할당할 수 있어서 특정 서버 및 서비스를 제공할 때 고정된 주소가 필요한 경우에 유용.

 

2) DHCP 서버에 따로 의존 하지 않기 때문에 네트워크 부하 및 장애에 영향을 받지 않음.

 

사용 목적 :

 

1) 서버, 라우터, 네트워크 장치 등과 같이 항상 동일한 IP 주소가 필요한 경우.

 

2) 특정 IP 주소를 사용 해서 고정 IP 주소로 네트워크 서비스를 제공 해야 하는 경우.

 

 

 

[ 정리 ]

 

네트워크 관리가 자동화 되고 동적으로 IP 주소를 할당 받을 필요가 있는 경우 : DHCP

 

특정 서버, 서비스, 장치, 라우터, .. 등등 항상 동일한 정적으로 IP 주소가 필요한 경우 : Static IP

 

 

 

* [ 참고 ]

 

Linux 환경의 IP / 이더넷 / 서브넷마스크 / 브로드캐스트 (tistory.com)

Linux 환경의 IP / 이더넷 / 서브넷마스크 / 브로드캐스트

 

6. ISVA를 구축할 때, ISVD (LDAP) 와 DB2의 설치 목적

 

 

ISVA (LDAP) 은 계층적인 트리 구조의 형태를 가진 소프트웨어 이다. 주로 사용자 및 그룹 등의 인증 및 인가 정보 등을 저장할 때 유용하다. 반면에 DB2는 다양한 종류의 정형화된 데이터를 관리 하고 저장 하는 관계형 데이터베이스 이다. 따라서 ISVD (LDAP) 와 DB2는 각각 사용 목적이 다른 소프트웨어 이다. 두 개를 모두 설치해서 아키텍처를 구현함으로써 ISVA에서 필요한 데이터 관리를 효과적으로 할 수 있게 되고, 사용자 중심의 서비스 관리를 효율적으로 수행할 수 있게 된다.

 

* LDAP : Lightweight Directory Access Protocol

경량의 디렉토리 서비스 프로토콜을 의미 한다.

계층적 디렉토리 구조를 가지기 때문에 데이터를 빠르게 조회 하고 갱신 하는데 최적화 되어 있다.

사용자 정보 및 데이터 정보를 관리하고 저장 한다.

ISVD는 LDAP을 제공 하는 서버 이다.

 

 

 

* DB2 : 

Oracle, MySQL, MariaDB, .. 등과 같은 테이블, 행, 열 등의 구조를 가진 RDBMS 이다.

기본적인 사용자 및 그룹 등 ISVA 솔루션에서 필요한 정보를 관리하고 저장 한다.

 

 

 

* [ 참고 ]

 

LDAP (Lightweight Directory Access Protocol) (tistory.com)

LDAP (Lightweight Directory Access Protocol)

 

DB2와 ISVD (LDAP) (tistory.com)

DB2와 ISVD (LDAP)

 

7. ISVA와 DB2는 직접적으로 통신 하지 않는다

 

 

 

ISVA Appliance에서 사용자의 요청을 WebSEAL이 받아서 Policy Server로 가게 된다.

(* Policy Server의 아키텍쳐가 local / remote 두 상황 모두 상관 없이 동일 하다)

 

LMI에서 Runtime Component를 구성 할 때, Policy Server와 LDAP (ISVD) 설정을 하게 된다.

 

이곳에서 각각의 서버를 Local로 둘지, Remote로 둘지 아키텍쳐에 따른 설정을 구성 한다.

 

따라서, ISVA는 Policy Server을 거쳐서 LDAP (ISVD) 와 통신 한다.

 

DB2는 LDAP (ISVD) 와 따로 연결 되어 있으며, 연결 설정은 설치한 LDAP 폴더 내부의 etc 폴더의 ldapdb.properties 파일에서 매핑 설정을 할 수 있다.

 

또한, SSL/TLS 프로토콜으로 DB2와 통신 하기 위해서 GSKit을 설치 하면 된다. 

 

* [ 참고 ]

 

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

ISVA (IBM Security Verify Access) 개념

 

ISVA Runtime Component 구성 하기 (tistory.com)

ISVA Runtime Component 구성 하기

 

ISVD (LDAP) GSkit 개념 및 GSkit 설치 방법 (tistory.com)

ISVD (LDAP) GSkit 개념 및 GSkit 설치 방법

 

8. SSO (Single Sign-On) 의 단점

 

 

SSO (Single Sign-On) : 단일 로그인으로 여러 서비스를 이용 할 수 있는 기술 이다.

 

따라서 한 번 로그인한 상황에서 사용자의 인증이 유출 되면 해당 사용자가 연결된 모든 서비스에 대해 위협을 받을 수 있게 된다. 따라서 사용자의 인증 정보가 유출 되지 않도록 적절한 보안 조치 및 프로토콜을 사용 해서 SSO를 구현할 수 있도록 해야 한다.

 

 

 

* [ 참고 ]

 

SSO (Single Sign-On) 란 ? (tistory.com)

SSO (Single Sign-On) 란 ?

 

 

9. ISVA에서 WebSEAL과 Junction의 역할은 무엇인가 ?

 

 

WebSEAL : ISVA에서 Reverse Proxy 역할을 한다. ISVA의 핵심 구성 요소이며, 클라이언트로 오는 HTTP 프로토콜 방식의 요청을 가로채고 WebSEAL에 연동 되어 있는 응용 프로그램 또는 자원 (서비스, 데이터, ..) 으로 요청을 전달 한다.

 

IBM 공식 자료에서, WebSEAL은 웹 기반 정보 및 자원을 보호 하는 리소스 관리자 라고 한다.

뿐만 아니라, SSO 솔루션을 제공 하고 백엔드 서버 자원을 보안 정책에 통합하여 관리할 수 있다고 한다.

 

Junction : WebSEAL로 들어온 사용자의 요청을 적절한 백엔드 서버로 매핑 해주는 역할을 한다.

Junction을 SSO (Single Sign-On) 솔루션의 대상 시스템으로 생각 해도 된다. 일반적으로 1 : 1 관계를 가진다.

 

 

 

[ 참고 ]

 

23.12.21 기준

 

LMI에서 Junction Management 탭을 클릭 해서 이용할 때, Virtual Host에 입력 하는 문자열이 곧 Junction의 Domain 개념이 되는듯 하다. 

 

WebSEAL은 여러 개의 Junction을 가질 수 있고, 각 Junction은 BackEnd 서버와 1 : 1로 매핑 되어 있다.

 

이때, 사용자의 요청은 일단 WebSEAL 서버로 가야 하기 때문에, WebSEAL 서버의 IP 주소를 입력 해야 하는데,

 

사용하는 웹 브라우저 OS의 Hosts 파일에 WebSEAL 서버의 IP 주소에 대응 하는 Domain 이름을 입력 한다.

(여러 개 입력 가능 하다)

 

이 Domain 이름을 Junction Management 에서 Virtual Host에 입력 했던 것과 일치 시켜야 한다.

 

* [ 참고 ]

 

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

ISVA (IBM Security Verify Access) 개념

 

WebSEAL introduction - IBM Documentation

WebSEAL introduction

 

10. Junction의 Standard Junction과 Virtual Junction의 차이점

 

 

Standard Junction :

 

WebSEAL에 연동된 BackEnd 서버가 모두 같은 도메인을 사용 하는 경우에 사용 가능 하다.

 

WebSEAL의 도메인이 a.bbb.co.kr 이라고 가정해보자.

 

이런 경우, Junction에 의해 매핑된 BackEnd 서버의 자원에 접근할 때 URL은 아래와 같이 된다.

 

예)

a.bbb.co.kr/abc

a.bbb.co.kr/def

a.bbb.co.kr/hij

..

 

이런식으로 사용자가 BackEnd 서버의 자원에 접근할 때 모두 같은 도메인을 갖게 된다.

/ (슬래시) 뒤에 요청값만 다른 것이다.

 

반면에, Virtual Junction은 Standard Junction과 전혀 다른 특징을 가진다.

 

 

 

Virtual Junction :

 

Junction이 가상의 호스트 (도메인) 을 가질 수 있게 된다.

 

따라서 사용자가 BackEnd 서버의 자원에 접근할 때, 각각의 자원은 모두 다른 도메인을 가질 수 있게 된다.

 

예)

 

WebSEAL 서버의 도메인이 a.bbb.co.kr 이라고 가정 할 때,

 

Virtual Junction A는 abc.hwanii.co.kr 이라는 호스트 (도메인) 를 갖는다.

 

Virtual Junction B는 def.hwanii.co.kr 이라는 호스트를 갖는다.

 

Virtual Junction C는 hij.hwanii.co.kr 이라는 호스트를 갖는다.

 

각각의 Virtual Junction에 매핑된 BackEnd 서버로 매핑 되게 된다.

 

WebSEAL의 도메인과는 전혀 상관 없는 상황 이다.

 

현재 ISVA Appliance를 사용 하고 있는 모든 서버에서는 Virtual Junction만 사용 하고 있다.

 

 

 

* [ 참고 ]

 

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

ISVA (IBM Security Verify Access) 개념