[Coursera Google] GCC IT 보안: 디지털 다크 아트로부터 보호 : AAA 보안(인증, LDAP, RADIUS, SSO, 액세스 제어 ...)

 

728x90

 

 

 

 

 

 

 

 

AAA 보안

인증

 

인증 권장사항

 

보안의 세 가지 A: 인증, 권한 부여, 계정 관리

 

1. 인증 (Authentication)

• 정의: 인증은 사용자가 자신이 주장하는 사람임을 증명하는 과정입니다.
• 예시: 이메일 로그인 시 이메일 주소와 비밀번호를 입력하는 과정.
• 인증의 구성 요소:
  • 식별자: 사용자 이름이나 이메일 주소.
  • 비밀번호: 식별자가 주장하는 본인임을 증명하는 정보.

2. 권한 부여 (Authorization)

• 정의: 권한 부여는 인증된 사용자가 특정 리소스에 접근할 권한이 있는지 결정하는 과정입니다.
• 예시: 이메일에 로그인한 후 자신의 받은편지함에는 접근할 수 있지만, 다른 사람의 받은편지함에는 접근할 수 없는 것.
• 구분:
  • authn: 인증(Authentication).
  • authz: 권한 부여(Authorization).

 

3. 계정 관리 (Account Management)

• 정의: 계정 관리는 사용자의 계정을 생성, 수정, 삭제하고 권한을 관리하는 전체적인 프로세스를 포함합니다.
• 목적: 계정 관리의 주요 목표는 사용자 계정의 보안을 유지하고, 권한을 적절히 부여 및 철회하는 것입니다.

 

비밀번호 보안

안전한 비밀번호의 조건

• 길이: 최소 12자 이상.
• 복잡성: 대문자, 소문자, 숫자, 특수 문자의 조합.
• 예시: Il1k3P0n1es!23

비밀번호의 취약점

• 짧고 단순한 비밀번호: ponies 같은 단순하고 짧은 비밀번호는 무차별 대입 공격에 취약.
• 비밀번호 패턴: 대체 프로세스 (Il1k3P0n1es)는 공격자에게 알려진 패턴일 수 있음.

보안성과 사용성의 균형

• 보안성과 사용성 상충: 비밀번호가 복잡하면 보안성이 높아지지만 사용성이 낮아짐.
• 예시: 복잡한 비밀번호는 기억하기 어렵지만 더 안전함.
• 해결책: 기억하기 쉬우면서도 안전한 비밀번호 사용.

비밀번호 정책

• 비밀번호 길이 및 복잡성: 길이 요구사항과 복잡한 문자 사용을 포함.
• 비밀번호 재사용 금지: 여러 계정에서 같은 비밀번호 사용 금지.
• 비밀번호 공유 금지: 비밀번호를 다른 사람과 공유하지 않음.
• 비밀번호 순환 정책: 정기적으로 비밀번호 변경 요구.
  • 주의: 너무 자주 변경을 요구하면 사용자가 비밀번호를 기록해두는 등의 부적절한 보안 행동을 유도할 수 있음.

추가 보안 조치

• 2단계 인증 (2FA): 비밀번호 외에 추가적인 인증 수단(예: 휴대전화 코드)을 사용하는 것.
• 보안 질문: 추가적인 본인 확인을 위해 보안 질문을 설정.
• 생체 인식: 지문, 얼굴 인식 등을 통해 인증.
• 암호 관리자: 복잡한 비밀번호를 안전하게 저장하고 관리하는 소프트웨어.

 

• 인증, 권한 부여, 계정 관리는 보안의 핵심 개념이며, 서로 밀접하게 관련되어 있습니다.
• 안전한 비밀번호 정책과 보안 조치를 통해 계정 보안을 강화해야 합니다.
• 보안성과 사용성의 균형을 맞추는 것이 중요합니다.

 

---

다중 인증

 

다중 인증 (Multi-Factor Authentication, MFA)

다중 인증은 사용자가 여러 가지 정보를 제공하여 자신의 정체성을 인증하는 시스템입니다. 다양한 인증 요소를 결합하여 보안을 강화할 수 있으며, 다음 세 가지 유형의 요소를 조합합니다:

1. 사용자가 알고 있는 요소: 비밀번호, PIN 등.
2. 사용자가 소유한 요소: 스마트폰, 보안 토큰 등.
3. 사용자의 고유한 요소: 지문, 홍채 등 생체 인식 데이터.

다중 인증의 유형

1. 물리적 토큰

• USB 보안 토큰: 비밀 토큰이 저장된 기기. 예: YubiKey.
• 독립형 기기: 일회용 비밀번호(OTP)를 생성하는 기기. 예: RSA SecurID 토큰.
• 일회용 비밀번호(OTP): 일정 시간마다 변하는 비밀번호로, 사용자 이름 및 비밀번호와 함께 사용.
  • 시간 기반 OTP (TOTP): 현재 시간과 비밀 시드를 조합해 생성.
  • 카운터 기반 OTP (HOTP): 비밀 시드와 카운터 값을 조합해 생성.

2. SMS 기반 다중 인증

• SMS OTP: SMS를 통해 사용자에게 일회용 비밀번호를 전송.
  • 장점: 널리 사용되고 설정이 쉬움.
  • 단점: 암호화되지 않으며, 이동통신사 보안에 의존. SMS 가로채기 공격에 취약.

3. 생체 인식

• 지문 인식: 스마트폰 잠금 해제 등에 사용.
• 홍채 인식: 홍채의 고유한 패턴을 사용.
• 얼굴 인식: 얼굴의 고유한 특징을 사용. 예: Windows Hello.
• 음성 인식: 사용자의 목소리를 사용.

4. U2F (Universal Second Factor)

• 개요: Google, Yubico, NXP Semiconductors가 개발한 표준.
• 기능: 공개 키 암호화와 시도-응답 메커니즘을 사용.
• 사용 방법:
  • 등록: 사이트에 고유한 비공개-공개 키 쌍을 생성하고, 공개 키를 제출.
  • 인증: 사용자 이름과 비밀번호 입력 후, 보안 키를 눌러 비공개 키로 시도 데이터에 서명.

다중 인증의 보안 및 사용성

• 보안성:
  • 향상된 보안: 여러 유형의 인증 요소를 결합하면 공격자가 여러 요소를 훔치거나 복제하기 어렵습니다.
  • 물리적 토큰 및 생체 인식: 피싱, 키로깅, 재사용 공격에 강함.
  • U2F: TLS 연결을 통한 인증으로 피싱 공격에 강함.
• 사용성:
  • 편의성: 물리적 토큰이나 생체 인식을 사용하는 경우 사용자가 쉽게 인증할 수 있습니다.
  • 불편함: 물리적 토큰 분실, 배터리 방전, 동기화 문제 등.

다중 인증의 구현 및 지원

• IT 지원 전문가의 역할:
  • 다중 인증 설정 및 지원: 사용 가능한 옵션을 이해하고, 향상된 계정 보호를 제공하는 방법을 습득.
  • 정책 수립: 조직의 보안 정책에 맞게 다중 인증 솔루션을 적용.
  • 교육 및 안내: 사용자에게 다중 인증의 중요성과 사용 방법을 교육.

다중 인증은 다양한 요소를 결합하여 보안성을 높이는 효과적인 방법입니다. 사용자는 비밀번호만 사용할 때보다 더 안전하게 계정을 보호할 수 있으며, 다양한 인증 방법을 조합하여 편의성과 보안성을 모두 충족할 수 있습니다. IT 지원 전문가로서 다중 인증의 중요성과 구현 방법을 이해하는 것은 매우 중요합니다.

 

 

---

인증서

 

클라이언트 인증서와 인증서 기반 인증

클라이언트 인증서는 서버가 클라이언트를 인증하고 확인할 수 있도록 클라이언트에서 제공되는 인증서입니다. 이는 TLS 서버 인증서와 유사하게 작동하지만, 클라이언트 쪽에서 제공됩니다. 클라이언트 인증서는 VPN 시스템이나 기업 Wi-Fi 설정에서 흔히 사용되며, IT 지원 전문가로서 이를 이해하는 것은 중요합니다.

클라이언트 인증서 발급 및 관리

1. 인증 기관 (CA):
   • 조직 내에서 CA를 설정하고 유지보수해야 합니다.
   • CA는 클라이언트 인증서를 발급하고 서명합니다.
   • 클라이언트와 서버 모두 신뢰할 수 있는 CA 인증서를 소유해야 합니다.
2. 상호 인증:
   • 클라이언트가 서버를 인증하는 것도 포함되어, 클라이언트가 신뢰할 수 있는 서버와 통신하고 있음을 확인합니다.
3. 인증서 신뢰 저장소:
   • 클라이언트와 서버는 모두 CA 인증서를 신뢰 저장소에 보관해야 합니다.
   • 이를 통해 인증서 신뢰가 설정됩니다.

인증서 기반 인증의 과정

1. 클라이언트 인증서 제공:
   • 클라이언트는 서버에 연결할 때 클라이언트 인증서를 제공합니다.
2. 서버의 클라이언트 인증서 검증:
   • 서버는 클라이언트 인증서를 확인하여 신뢰할 수 있는 CA에서 서명되었는지 검증합니다.
   • 인증서의 유효 기간을 확인하여 만료되지 않았는지 확인합니다.
   • 인증서를 해지 인증서 목록(CRL)과 비교하여 인증서가 해지되지 않았는지 확인합니다.
3. 비공개 키 소유 증명:
   • 클라이언트는 서버가 제공하는 무작위 데이터에 비공개 키로 서명하여 비공개 키 소유를 증명합니다.
   • 서버는 클라이언트의 서명을 검증하여 클라이언트가 실제 비공개 키 소유자인지 확인합니다.

유효 기간 및 해지 인증서 목록(CRL)

• 유효 기간:
  • 유효 기간 시작일: 인증서가 유효한지 여부를 확인.
  • 유효 기간 종료일: 인증서가 만료되었는지 여부를 확인.
• 해지 인증서 목록(CRL):
  • CA에서 발행한 해지된 인증서 목록입니다.
  • 서버는 인증서를 CRL과 비교하여 인증서가 해지되지 않았는지 확인합니다.

비공개 키 소유 증명 (시도-응답 메커니즘)

• 시도-응답 메커니즘:
  • 서버는 클라이언트에게 무작위 데이터를 보내고, 클라이언트는 비공개 키로 서명하여 반환합니다.
  • 서버는 반환된 서명을 공개 키로 검증하여 클라이언트의 비공개 키 소유를 확인합니다.

클라이언트 인증서의 중요성

• 보안 강화:
  • 클라이언트 인증서는 강력한 인증 방법으로, 비밀번호만 사용하는 것보다 훨씬 더 안전합니다.
  • 인증서 기반 인증은 피싱 및 중간자 공격에 대한 저항력이 높습니다.
• IT 지원 역할:
  • 클라이언트 인증서 발급 및 관리에 대한 이해는 IT 지원 전문가로서 중요합니다.
  • 조직의 보안 정책에 맞게 인증서를 설정하고 문제를 해결하는 능력이 필요합니다.

클라이언트 인증서와 인증서 기반 인증을 이해하고 이를 적용하면 조직의 보안 수준을 높일 수 있습니다. IT 지원 전문가로서 이러한 기술을 습득하고 관리하는 것은 필수적인 능력입니다.

 

---

LDAP

 

LDAP(경량 디렉터리 액세스 프로토콜)는 디렉터리 서비스에 액세스하고 이를 유지보수하는 데 사용되는 개방형 표준 프로토콜입니다. LDAP는 디렉터리의 데이터 구조를 설명하고, 조회 수행 및 데이터 수정 등 디렉터리와 상호작용하는 기능을 정의합니다. LDAP 디렉터리는 계층적 트리 구조를 가지고 있으며, 데이터 작성보다는 조회에 최적화되어 있습니다. 이는 전화번호부와 유사하게 데이터를 수정하기보다는 데이터를 조회하는 데 더 자주 사용됩니다.

 

LDAP 디렉터리 구조

LDAP 디렉터리는 일종의 트리 레이아웃을 갖추고 있으며, 데이터는 트리의 각 노드에 저장됩니다. 각 노드는 디렉터리 항목(Entry)으로 구성되며, 각 항목에는 여러 속성(Attribute)이 포함됩니다. 이러한 트리 구조는 객체의 상속 및 중첩을 허용하여, 상위 객체의 속성이 하위 객체에 의해 상속될 수 있습니다.

 

디렉터리 항목 및 속성

• 항목(Entry): 디렉터리의 각 항목은 개별 사용자, 그룹 또는 리소스에 대한 정보를 포함합니다.
• 속성(Attribute): 각 항목에는 이름, 성, 전화번호, 이메일 주소, 로그인 셸 등 다양한 속성이 포함됩니다.
• 고유 이름(DN): 디렉터리 항목의 고유 식별자로, 항목의 전체 경로를 나타냅니다. 파일 시스템의 정규화된 경로와 유사하게, DN은 트리 내의 고유한 위치를 설명합니다.

조직 단위(OU) 및 상속

LDAP 트리 구조에서 폴더는 조직 단위(OU)라고 하며, 관련된 객체를 그룹화하는 데 사용됩니다. 각 OU는 상위 객체와 하위 객체를 포함할 수 있으며, 상위 객체의 속성을 하위 객체가 상속받을 수 있습니다.

 

일반적인 LDAP 작업

클라이언트가 LDAP 서버와 상호작용할 때 수행할 수 있는 일반적인 작업은 다음과 같습니다:

1. 바인딩(Bind): 클라이언트가 서버에 대해 인증하는 방식입니다.
2. StartTLS: TLS를 통해 LDAP v3를 사용하여 클라이언트와 서버 간의 통신을 암호화합니다.
3. 검색(Search): 디렉터리에서 레코드를 조회하고 검색합니다.
4. 추가(Add)/삭제(Delete)/수정(Modify): 디렉터리에 데이터를 쓰고 수정합니다.
5. 바인딩 해제(Unbind): LDAP 서버와의 연결을 닫습니다.

LDAP 서버 구현

LDAP 서버의 다양한 구현이 있으며, 대표적인 예로는 Microsoft의 Active Directory와 오픈소스 구현을 위한 OpenLDAP이 있습니다. 이러한 LDAP 서버는 디렉터리 정보를 저장하고 관리하며, 클라이언트가 디렉터리 서비스에 액세스하고 이를 활용할 수 있도록 지원합니다.

 

LDAP는 디렉터리 서비스의 액세스 및 유지보수에 중요한 역할을 하며, 디렉터리 구조와 상호작용하는 방식을 이해하면 LDAP 기반 시스템을 효과적으로 관리할 수 있습니다.

 

 

 

---

RADIUS

 

RADIUS(Remote Authentication Dial-In User Service)는 네트워크 사용자에게 AAA(인증, 권한 부여, 계정 관리) 서비스를 제공하는 프로토콜입니다. 이는 네트워크 액세스를 제어하고 사용자 자격 증명을 검증하는 데 널리 사용됩니다. RADIUS는 주로 내부 네트워크, Wi-Fi 네트워크, 이메일 서비스, VPN 서비스 등 다양한 네트워크 환경에서 사용됩니다.

 

RADIUS의 역할 및 작동 원리

RADIUS 서버는 사용자가 네트워크에 액세스할 때 인증, 권한 부여 및 계정 관리 기능을 제공합니다. RADIUS 프로토콜은 클라이언트의 자격 증명을 인증하고 사용자가 네트워크에 액세스할 수 있는 권한을 부여하며, 액세스 기록을 남기는 데 사용됩니다.

 

RADIUS 인증 과정

1. 클라이언트 요청: 사용자가 네트워크 리소스에 액세스하려고 하면, 클라이언트(사용자의 장치)는 네트워크 액세스 서버(NAS)로 자격 증명을 전송합니다.
2. NAS 릴레이: NAS는 클라이언트의 자격 증명을 수신하고 이를 RADIUS 서버로 전달합니다.
3. RADIUS 서버 검증: RADIUS 서버는 수신된 자격 증명을 구성된 인증 스키마에 따라 검증합니다. RADIUS 서버는 여러 종류의 인증 소스를 사용할 수 있습니다:
   • 플랫 파일: 서버에 저장된 텍스트 파일
   • SQL 데이터베이스: 사용자 정보를 저장하는 데이터베이스
   • LDAP: 디렉터리 서비스
   • Kerberos: 인증 프로토콜
   • Active Directory: Microsoft의 디렉터리 서비스
4. 응답: 자격 증명이 검증되면 RADIUS 서버는 NAS로 응답을 보냅니다. 응답 유형은 세 가지입니다:
   • Access-Reject(액세스 거부): 자격 증명이 유효하지 않거나 인증에 실패한 경우
   • Access-Challenge(액세스 시도): 추가 정보를 요청하는 경우(예: 2단계 인증)
   • Access-Accept(액세스 수락): 자격 증명이 유효하고 사용자가 네트워크에 액세스할 수 있는 경우

RADIUS의 구성 요소

• RADIUS 서버: 인증, 권한 부여 및 계정 관리를 수행하는 중앙 서버
• NAS(Network Access Server): 클라이언트의 자격 증명을 받아 RADIUS 서버로 전달하는 장치
• 클라이언트: 네트워크 리소스에 액세스하려는 사용자 장치

RADIUS의 주요 특징

• 확장성: EAP(Extensible Authentication Protocol)와 같은 다양한 표준 인증 프로토콜을 지원
• 유연성: 다양한 인증 소스(플랫 파일, SQL 데이터베이스, LDAP, Kerberos, Active Directory)와 통합 가능
• 보안: 사용자 자격 증명을 안전하게 전송하고 검증

예시 시나리오

1. VPN 액세스: 사용자가 VPN에 접속하려고 하면 클라이언트는 NAS에 자격 증명을 전송합니다. NAS는 이를 RADIUS 서버로 릴레이하고, 서버는 자격 증명을 검증한 후 액세스 권한을 부여합니다.
2. Wi-Fi 네트워크: 사용자가 회사의 Wi-Fi 네트워크에 접속하려고 하면, 클라이언트는 NAS(예: 무선 액세스 포인트)에 자격 증명을 전송합니다. NAS는 이를 RADIUS 서버로 릴레이하고, 서버는 자격 증명을 검증한 후 네트워크 액세스를 허용합니다.

 

RADIUS는 네트워크 사용자에게 AAA 서비스를 제공하는 강력하고 유연한 프로토콜입니다. RADIUS 서버와 클라이언트 간의 상호작용을 이해하면, 네트워크 액세스와 관련된 문제를 보다 효과적으로 해결할 수 있습니다. IT 지원 전문가로서 RADIUS에 대한 이해는 네트워크 관리와 보안 강화에 큰 도움이 됩니다.

 

---

Kerberos

 

Kerberos는 티켓을 사용하여 개체가 잠재적으로 안전하지 않은 채널을 통해 자신의 신원을 증명할 수 있도록 하는 네트워크 인증 프로토콜입니다. Kerberos는 상호 인증을 제공하며, 대칭 암호화를 사용하여 도청 및 재생 공격으로부터 프로토콜 메시지를 보호합니다. 이 프로토콜의 이름은 지하 세계의 문을 지키는 머리 셋 달린 경비견 Kerberos에서 유래되었습니다.

 

Kerberos는 원래 미국의 매사추세츠 공과대학교에서 개발되었으며, 1980년대에 버전 4가 공개되고 1993년에 버전 5가 공개되었습니다. 현재는 AES 암호화를 지원하고 데이터 무결성 및 기밀성을 보장하는 체크섬을 구현하고 있습니다.

 

Kerberos의 작동 원리

Kerberos 인증은 티켓을 사용하여 클라이언트와 서버 간의 상호 인증을 수행합니다. 다음은 Kerberos 프로토콜의 작동 과정을 단계별로 설명합니다.

1. 사용자 인증 요청: 사용자가 클라이언트 시스템에 사용자 이름과 비밀번호를 입력하면, Kerberos 클라이언트 소프트웨어는 비밀번호를 가져와서 대칭 암호화 키를 생성합니다. 클라이언트는 사용자 ID를 일반 텍스트 메시지로 Kerberos 인증 서버(AS)로 전송합니다. 이때 비밀번호나 비밀번호에서 파생된 비밀 키는 전송되지 않습니다.
2. AS 인증 및 TGT 발급: AS는 사용자 ID를 사용하여 인증 데이터베이스(예: Active Directory)에서 계정을 확인합니다. 계정이 있으면 AS는 저장된 해싱된 비밀번호를 사용하여 비밀 키를 생성합니다. 그런 다음 AS는 이 비밀 키를 사용하여 클라이언트 TGS 세션 키를 포함하는 메시지를 암호화하고 전송합니다. 또한 AS는 TGS 비밀 키를 사용하여 암호화된 티켓 부여 티켓(TGT)을 전송합니다. 이 TGT에는 클라이언트 ID, 티켓 유효 기간, 부여 서비스 세션 키를 사용하는 클라이언트 정보가 포함됩니다.
3. TGS 요청 및 서비스 티켓 발급: 클라이언트는 받은 TGT를 사용하여 티켓 부여 서비스(TGS)에 서비스 액세스를 요청합니다. 이때 클라이언트는 액세스를 요청하는 서비스 이름 또는 ID와 함께 암호화된 TGT 및 클라이언트 ID, 타임스탬프를 포함하는 인증자를 TGS에 전송합니다. TGS는 TGT를 해독하여 클라이언트 ID와 타임스탬프를 확인한 후, 클라이언트-서버 세션 키로 구성된 서비스 티켓을 발급합니다.
4. 서비스 인증: 클라이언트는 서비스 서버(SS)에 서비스 티켓과 클라이언트 ID, 타임스탬프를 포함하는 인증자를 전송합니다. SS는 서비스 티켓을 해독하여 클라이언트 ID를 확인하고, 클라이언트-서버 세션 키로 암호화된 타임스탬프를 클라이언트에게 전송합니다. 클라이언트는 이를 해독하여 타임스탬프가 정확한지 확인하고 서버를 인증합니다.

Kerberos의 장점

1. 강력한 보안: 대칭 암호화를 사용하여 통신을 보호하고, 티켓 기반 인증으로 도청 및 재생 공격을 방지합니다.
2. 상호 인증: 클라이언트와 서버 간의 상호 인증을 통해 양쪽 모두 신뢰할 수 있는 상태를 확인합니다.
3. 단일 로그인: 사용자가 한 번 인증되면 티켓을 사용하여 여러 서비스에 접근할 수 있어 편리합니다.

Kerberos의 단점

1. 단일 장애점: Kerberos 서버가 다운되면 새로운 사용자는 인증할 수 없게 됩니다.
2. 시간 동기화 필요: Kerberos는 엄격한 시간 요구 사항이 있어 클라이언트와 서버 시계가 동기화되지 않으면 인증이 실패할 수 있습니다.
3. 신뢰 모델의 한계: 클라이언트와 서비스가 Kerberos 서버에 대해 설정된 신뢰가 있어야 하므로, BYOD(Bring Your Own Device) 및 클라우드 컴퓨팅 환경에서는 구현이 어렵습니다.

Kerberos의 사용 사례

1. Windows 도메인: Windows 2000 이상 버전에서는 Kerberos를 기본 인증 프로토콜로 사용합니다. Microsoft는 Kerberos를 약간 수정하여 자체 Kerberos 서비스를 구현했습니다.
2. 네트워크 서비스: 다양한 네트워크 서비스에서 Kerberos를 사용하여 안전한 인증을 수행합니다.

 

Kerberos는 네트워크 인증을 위한 강력하고 신뢰할 수 있는 프로토콜입니다. 티켓 기반 인증과 대칭 암호화를 통해 보안을 강화하고, 상호 인증을 통해 신뢰성을 제공합니다. IT 지원 전문가로서 Kerberos의 작동 방식을 이해하면 네트워크 인증과 관련된 문제를 효과적으로 해결할 수 있습니다.

 

 

---

TACACS+

 

TACACS+는 터미널 액세스 컨트롤러 액세스 제어 시스템 플러스(Terminal Access Controller Access-Control System Plus)의 약자로, Cisco가 개발한 AAA(인증, 권한 부여, 계정 관리) 프로토콜입니다. 1993년에 개방형 표준으로 출시되었으며, 1984년에 MILNET용으로 개발된 기존 TACACS 프로토콜을 대체했습니다. MILNET은 DARPA의 비 기밀 네트워크로, 나중에 NIPRNet으로 발전했습니다. TACACS+는 TACACS뿐만 아니라 Cisco의 독점 확장 프로그램인 XTACACS도 대체했습니다.

 

TACACS+의 주요 기능과 사용 사례

TACACS+는 주로 네트워크 인프라 기기의 관리, 인증, 권한 부여, 계정 관리를 위해 사용됩니다. 이는 RADIUS와 같은 다른 AAA 프로토콜과 몇 가지 중요한 차이점을 가지고 있습니다.

1. 인증(Authentication): 사용자가 시스템에 접근하려고 할 때, TACACS+는 사용자의 자격 증명을 확인하여 인증합니다. 인증 과정에서 사용자 이름과 비밀번호뿐만 아니라, 토큰이나 스마트 카드와 같은 추가적인 인증 방법을 지원할 수 있습니다.
2. 권한 부여(Authorization): 사용자가 인증된 후, TACACS+는 사용자가 수행할 수 있는 작업을 결정합니다. 이는 사용자마다 다른 권한을 설정할 수 있게 하여, 특정 사용자에게는 일부 명령어 실행을 허용하고, 다른 사용자에게는 제한할 수 있습니다.
3. 계정 관리(Accounting): TACACS+는 사용자의 활동을 기록합니다. 이는 누가, 언제, 어떤 작업을 수행했는지를 추적할 수 있게 하여, 보안 감사와 문제 해결에 유용합니다.

TACACS+와 RADIUS의 비교

TACACS+와 RADIUS는 모두 AAA 프로토콜이지만, 그 용도와 특성에서 차이가 있습니다.

1. 프로토콜 구조:
   • TACACS+는 TCP를 사용하여 더 안정적이고, 세션 기반의 통신을 지원합니다.
   • RADIUS는 UDP를 사용하여 빠른 성능을 제공하지만, 패킷 손실에 더 취약합니다.
2. 암호화:
   • TACACS+는 전체 페이로드를 암호화하여 더 높은 보안을 제공합니다.
   • RADIUS는 사용자 비밀번호만 암호화하며, 나머지 페이로드는 평문으로 전송됩니다.
3. 사용 목적:
   • TACACS+는 주로 네트워크 인프라 기기의 관리와 관련된 인증, 권한 부여, 계정 관리에 사용됩니다.
   • RADIUS는 주로 네트워크 접속과 관련된 AAA 서비스에 사용됩니다.

TACACS+의 구현과 보안

TACACS+는 주로 네트워크 인프라 기기에서 사용되며, 다음과 같은 보안 이유로 중요한 타겟이 될 수 있습니다.

1. 중앙 집중 관리: TACACS+ 서버를 통해 여러 네트워크 기기의 인증, 권한 부여, 계정 관리를 중앙에서 일괄적으로 관리할 수 있습니다.
2. 높은 보안성: 전체 페이로드를 암호화하여 네트워크 스니핑을 방지하고, 기기 관리자의 명령어 실행을 제한하여 권한 남용을 방지합니다.
3. 세분화된 권한 관리: 특정 명령어에 대한 실행 권한을 사용자별로 세분화하여 설정할 수 있어, 불필요한 권한 부여를 최소화할 수 있습니다.

 

TACACS+는 네트워크 인프라 기기 관리와 관련된 AAA 서비스를 제공하는 데 매우 효과적인 프로토콜입니다. 높은 보안성과 세분화된 권한 관리 기능을 제공하여, 대규모 조직의 네트워크 관리에 유용합니다. IT 지원 전문가로서 TACACS+의 기본 원리와 특징을 이해하면, 네트워크 인프라와 관련된 문제를 더 잘 해결할 수 있으며, 조직의 보안을 강화하는 데 기여할 수 있습니다.

 

 

---

싱글 사인온(SSO)

 

싱글 사인온(SSO)은 한 번의 인증을 통해 여러 애플리케이션과 서비스에 접근할 수 있도록 하는 편리한 인증 방식입니다. SSO의 주요 개념과 작동 방식, 장단점을 이해하기 위해 아래 내용을 정리했습니다.

 

SSO의 작동 방식

1. 사용자 인증: 사용자가 SSO 시스템에 한 번 로그인하여 인증합니다.
2. 토큰 또는 쿠키 발행: 인증이 완료되면 SSO 시스템은 사용자가 접근하려는 애플리케이션과 서비스에 접근할 수 있는 토큰 또는 쿠키를 발행합니다.
3. 서비스 접근: 사용자는 이 토큰 또는 쿠키를 사용하여 추가적인 로그인 없이 여러 애플리케이션과 서비스에 접근할 수 있습니다.

Kerberos와 SSO

Kerberos는 SSO 시스템의 좋은 예입니다. Kerberos의 SSO 작동 방식은 다음과 같습니다:

1. 사용자가 Kerberos 인증 서버(AS)에 로그인하여 인증합니다.
2. AS는 사용자에게 티켓 부여 티켓(TGT)을 발급합니다.
3. 사용자는 서비스를 이용할 때 이 TGT를 티켓 부여 서비스(TGS)에 제출합니다.
4. TGS는 서비스 티켓을 발급하여 사용자가 여러 서비스에 접근할 수 있도록 합니다.

SSO의 장점

1. 편리함: 사용자는 여러 애플리케이션과 서비스에 접근하기 위해 여러 번 로그인할 필요가 없습니다.
2. 보안 강화: 단일 자격 증명을 사용하여 여러 서비스에 접근하기 때문에 비밀번호를 기록하거나 저장할 필요가 줄어듭니다.
3. 관리 효율성: 비밀번호 지원에 대한 오버헤드가 줄어들고, 사용자가 재인증하는 데 걸리는 시간이 줄어듭니다.

SSO의 단점

1. 보안 리스크: SSO 계정이 손상되면, 공격자는 이 계정이 접근할 수 있는 모든 애플리케이션과 서비스에 접근할 수 있게 됩니다.
2. 세션 토큰 도난: 공격자가 SSO 세션 쿠키 또는 토큰을 도난하면, 해당 토큰의 유효 기간 동안 광범위한 접근 권한을 가질 수 있습니다. 이는 다중 인증(MFA)을 회피할 수 있는 위험을 초래합니다.

 

OpenID 예시

OpenID는 중앙 집중식 인증 시스템의 한 예로, 다음과 같은 방식으로 작동합니다:

1. 인증 요청: 사용자가 신뢰 당사자(사이트)에서 접근을 시도할 때, 신뢰 당사자는 OpenID 공급업체를 통해 사용자의 인증을 요청합니다.
2. 인증 흐름: 사용자는 OpenID 공급업체의 인증 페이지로 리디렉션되어 로그인합니다.
3. 사용자 승인: 사용자가 신뢰 당사자를 신뢰하는지 확인합니다.
4. 인증 토큰 발행: 인증이 완료되면, OpenID 공급업체는 신뢰 당사자에게 사용자 인증을 확인하는 토큰을 발행합니다.
5. 서비스 접근: 신뢰 당사자는 이 토큰을 사용하여 사용자를 인증하고 서비스에 접근할 수 있도록 합니다.

 

SSO는 한 번의 인증으로 여러 애플리케이션과 서비스에 접근할 수 있도록 하여 사용자에게 편리함을 제공하지만, 계정 손상 시 보안 리스크가 커질 수 있습니다. 따라서 SSO와 함께 다중 인증(MFA)을 사용하는 것이 중요합니다. OpenID는 중앙 집중식 인증 시스템의 예로, 인증 인프라를 사이트 자체에 구현하지 않고도 사용자 인증을 가능하게 합니다.

 

 

---

권한 부여

 

권한 부여 및 액세스 제어 방법

 

권한 부여는 인증과 밀접하게 연관된 개념으로, 사용자가 특정 리소스나 서비스에 접근할 수 있는 권한을 결정하는 과정입니다. 인증이 사용자의 신원을 확인하는 것이라면, 권한 부여는 그 사용자가 어떤 작업을 수행할 수 있는지 결정하는 것입니다. 이 둘은 AAA의 세 가지 A 중 각각 다른 부분을 차지하며, 함께 작동하여 시스템 보안을 유지합니다.

 

권한 부여의 개념

1. 인증과 권한 부여의 차이점:
   • 인증(Authentication): 사용자가 누구인지 확인하는 과정입니다. 예를 들어, 사용자가 올바른 사용자 이름과 비밀번호를 입력하면 시스템이 그 사용자의 신원을 확인합니다.
   • 권한 부여(Authorization): 인증된 사용자가 시스템에서 무엇을 할 수 있는지를 결정하는 과정입니다. 즉, 사용자가 어떤 리소스에 접근할 수 있고, 어떤 작업을 수행할 수 있는지에 대한 권한을 부여하는 것입니다.

Kerberos와 권한 부여

Kerberos 인증 프로세스에서 권한 부여는 다음과 같이 작동합니다:

1. 사용자 인증: 사용자가 인증 서버(AS)에서 인증을 받아 티켓 부여 티켓(TGT)을 받습니다.
2. 서비스 요청: 사용자가 티켓 부여 서비스(TGS)에 특정 서비스에 대한 접근을 요청합니다.
3. 권한 부여 결정: TGS는 사용자가 요청한 서비스에 대한 접근 권한이 있는지 확인합니다. 권한이 있다면 TGS는 해당 서비스에 접근할 수 있는 티켓을 발급합니다. 권한이 없다면 요청이 거부됩니다.

OAuth: 권한 부여의 개방형 표준

OAuth(Open Authorization)는 권한 부여를 위한 개방형 표준으로, 많은 대형 IT 기업에서 사용되고 있습니다. OAuth는 사용자 계정의 자격 증명을 노출하지 않고 제3자 애플리케이션이 사용자 자원에 접근할 수 있도록 권한을 부여하는 방식으로 작동합니다.

1. OAuth 개요:
   • OAuth는 애플리케이션이 사용자 자원에 접근할 수 있도록 권한을 부여하는 프로토콜입니다.
   • OAuth는 사용자가 자신의 자격 증명을 노출하지 않고도 다른 애플리케이션이 특정 자원에 접근할 수 있도록 허용합니다.
2. OAuth의 주요 역할:
   • 리소스 소유자(Resource Owner): 자원(데이터)을 소유한 사용자입니다.
   • 클라이언트(Client): 리소스 소유자의 자원에 접근하려는 애플리케이션입니다.
   • 리소스 서버(Resource Server): 실제 자원이 저장된 서버입니다.
   • 권한 부여 서버(Authorization Server): 사용자의 권한을 인증하고 토큰을 발급하는 서버입니다.
3. OAuth 작동 방식:
   • 권한 요청: 클라이언트 애플리케이션이 리소스 소유자에게 권한을 요청합니다.
   • 사용자 승인: 리소스 소유자는 클라이언트 애플리케이션에 권한을 부여합니다.
   • 토큰 발급: 권한 부여 서버는 클라이언트 애플리케이션에 접근 토큰을 발급합니다.
   • 자원 접근: 클라이언트 애플리케이션은 접근 토큰을 사용하여 리소스 서버에 접근하고 자원을 요청합니다.

 

권한 부여는 사용자가 인증된 이후에 그 사용자가 어떤 리소스에 접근할 수 있는지를 결정하는 중요한 보안 과정입니다. Kerberos와 같은 시스템에서 권한 부여는 티켓 부여 서비스(TGS) 단계에서 이루어지며, OAuth와 같은 개방형 표준은 권한 부여를 위해 널리 사용되고 있습니다. OAuth는 특히 사용자가 자신의 자격 증명을 노출하지 않고도 다양한 애플리케이션이 자원에 접근할 수 있도록 허용하여 보안성과 편리성을 모두 제공합니다.

 

---

액세스 제어

 

OAuth: 권한 부여의 개방형 표준

OAuth는 사용자가 계정 자격 증명을 공유하지 않고도 제3자 웹사이트 및 애플리케이션에 자신의 정보에 대한 액세스 권한을 부여할 수 있도록 설계된 개방형 표준입니다. 이는 사용자가 특정 데이터나 서비스에 대한 접근을 승인하는 방법으로, 사용자에게 안전하고 편리한 방식으로 권한을 위임할 수 있는 수단을 제공합니다.

 

OAuth의 작동 방식

1. 사용자 인증 및 승인:
   • 사용자는 제3자 애플리케이션이 자신의 데이터에 접근할 수 있도록 승인합니다. 이 과정에서 사용자에게는 해당 애플리케이션이 어떤 권한을 요청하는지에 대한 명확한 정보가 제공됩니다.
2. 권한 부여 코드 발급:
   • 사용자가 요청을 승인하면 권한 부여 서버는 제3자 애플리케이션에 권한 부여 코드를 발급합니다.
3. 액세스 토큰 발급:
   • 제3자 애플리케이션은 권한 부여 코드를 사용하여 권한 부여 서버로부터 액세스 토큰을 발급받습니다.
4. 리소스 서버 접근:
   • 제3자 애플리케이션은 액세스 토큰을 사용하여 사용자의 데이터에 접근할 수 있습니다.

 

OAuth 사용 예시

예를 들어, 사용자가 밈 생성 웹사이트를 사용하여 이메일로 밈을 보내려고 한다고 가정해보겠습니다. 이 웹사이트는 사용자의 이메일 제공업체를 통해 OAuth를 요청하여 사용자의 이메일 계정에 대한 접근 권한을 얻습니다. 사용자가 이를 승인하면 이메일 제공업체는 웹사이트에 액세스 토큰을 발급하여 사용자의 이메일 계정에 대한 권한을 부여합니다. 이 액세스 토큰은 이메일에만 사용되며, 다른 서비스에는 접근할 수 없습니다.

 

OAuth의 보안 고려사항

OAuth를 사용할 때 주의해야 할 보안 고려사항은 다음과 같습니다:

• 피싱 공격: 공격자는 피싱 이메일을 통해 사용자가 OAuth 권한을 부여하도록 유도할 수 있습니다. 이는 자격 증명을 손상시키지 않고도 계정에 접근할 수 있는 방법입니다.
• 토큰 도용: 액세스 토큰이 도용될 경우, 공격자는 이를 사용하여 사용자의 데이터에 접근할 수 있습니다.

 

OpenID와 OAuth의 차이점

• OpenID: 주로 인증에 사용되는 표준으로, 사용자가 누구인지 확인하는 데 중점을 둡니다.
• OAuth: 주로 권한 부여에 사용되는 표준으로, 제3자 애플리케이션이 사용자 데이터에 접근할 수 있도록 허용합니다.
• OpenID Connect: OAuth 2.0 위에 구축된 인증 계층으로, OpenID와 OAuth의 기능을 통합하여 더 나은 인증 및 권한 부여를 제공합니다.

TACACS+와 권한 부여

TACACS+는 Cisco에서 개발한 AAA(인증, 권한 부여, 계정 관리) 프로토콜로, 주로 네트워크 인프라 기기의 관리에 사용됩니다.

• 인증: 사용자의 신원을 확인합니다.
• 권한 부여: 사용자가 수행할 수 있는 작업을 결정합니다.
• 계정 관리: 사용자의 활동을 기록하고 모니터링합니다.

TACACS+는 명령어 수준까지 권한 부여를 세분화할 수 있으며, 이를 통해 특정 사용자나 그룹에 대해 매우 세부적인 액세스 권한을 부여할 수 있습니다. 예를 들어, 네트워킹 팀에게는 네트워크 장비의 구성 및 유지보수를 위한 관리자 액세스를 부여하고, 지원 팀에게는 읽기 전용 액세스를 제공하는 식입니다.

 

RADIUS와 권한 부여

RADIUS는 네트워크 접근을 관리하기 위한 또 다른 AAA 프로토콜로, 주로 네트워크 접속(예: Wi-Fi, VPN)에 사용됩니다.

• 인증: 사용자가 네트워크에 접근할 때 신원을 확인합니다.
• 권한 부여: 사용자가 접근할 수 있는 네트워크 리소스를 결정합니다.
• 계정 관리: 사용자의 네트워크 사용 내역을 기록합니다.

RADIUS 서버는 네트워크 접근 서버(NAS)에 구성 정보를 반환하여 사용자가 접근할 수 있는 네트워크 서비스를 지정합니다. 예를 들어, 일부 사용자에게는 Wi-Fi 및 VPN 접근을 허용하고, 다른 사용자에게는 이를 제한할 수 있습니다.

 

권한 부여는 사용자가 인증된 후 시스템에서 수행할 수 있는 작업을 결정하는 과정입니다. OAuth는 사용자 자격 증명을 공유하지 않고도 제3자 애플리케이션에 접근 권한을 부여하는 표준이며, OpenID는 주로 인증에 사용됩니다. TACACS+와 RADIUS는 네트워크 인프라 관리 및 네트워크 접근 관리를 위한 AAA 프로토콜로, 각각 다양한 권한 부여 기능을 제공합니다. 이러한 프로토콜과 표준을 이해하면, IT 환경에서 보다 안전하고 효율적인 권한 관리를 구현할 수 있습니다.

 

---

액세스 제어 목록

 

액세스 제어 목록(ACL)

ACL(Access Control List)은 시스템의 객체에 대한 접근 권한을 정의하는 중요한 보안 메커니즘입니다. 이를 통해 파일 시스템, 네트워크 장비 등에서 세부적인 접근 제어를 설정할 수 있습니다.

 

파일 시스템에서의 ACL

파일 시스템에서 ACL은 폴더, 파일 또는 프로그램과 같은 객체에 대한 접근 권한을 관리합니다. 다음은 파일 시스템에서 ACL의 주요 구성 요소입니다:

• ACL(Access Control List): 객체에 대한 접근 권한을 정의하는 항목들의 리스트입니다.
• ACE(Access Control Entry): ACL을 구성하는 개별 항목으로, 특정 사용자나 그룹이 객체에 대해 어떤 권한을 가지는지를 정의합니다.

파일 시스템 ACL에서 각 ACE는 다음과 같은 권한을 정의할 수 있습니다:

• 읽기(Read): 객체의 내용을 읽을 수 있는 권한.
• 쓰기(Write): 객체의 내용을 수정할 수 있는 권한.
• 실행(Execute): 객체를 실행할 수 있는 권한(주로 프로그램 파일에 적용).

이러한 접근 권한은 사용자의 보안 수준을 세밀하게 설정할 수 있게 해줍니다.

 

네트워크에서의 ACL

네트워크 환경에서는 ACL이 라우터, 스위치, 방화벽 등의 장비에서 사용됩니다. 네트워크 ACL은 들어오고 나가는 트래픽을 제어하며, 이를 통해 네트워크 보안을 강화할 수 있습니다.

 

네트워크 ACL의 주요 기능은 다음과 같습니다:

• 트래픽 필터링: 특정 IP 주소, 포트 번호, 프로토콜을 기반으로 트래픽을 허용하거나 차단합니다.
• 정책 시행: 조직의 보안 정책을 enforce하기 위해 네트워크 접근을 제한합니다.
• 데이터 전송 방지: 무단 데이터 유출을 방지하기 위해 나가는 트래픽을 제한합니다.

네트워크 ACL은 주로 두 가지 유형으로 나뉩니다:

• 표준 ACL: 소스 IP 주소를 기반으로 트래픽을 필터링합니다.
• 확장 ACL: 소스 및 목적지 IP 주소, 포트 번호, 프로토콜을 포함한 다양한 기준을 기반으로 트래픽을 필터링합니다.

 

예시

1. 파일 시스템 ACL 예시:
   • 파일 example.txt에 대해 사용자 Alice에게 읽기 및 쓰기 권한을 부여하고, 사용자 Bob에게 읽기 권한만 부여하는 ACL:
     mathematica

     코드 복사

     example.txt - Alice: Read, Write - Bob: Read
2. 네트워크 ACL 예시:
   • 내부 네트워크(192.168.1.0/24)에서 외부 네트워크로 나가는 HTTP 트래픽(포트 80)을 허용하고, 다른 모든 트래픽을 차단하는 ACL:
     arduino

     코드 복사

     permit tcp 192.168.1.0 0.0.0.255 any eq 80 deny ip any any

 

ACL은 객체에 대한 접근 권한을 정의하는 중요한 보안 도구입니다. 파일 시스템 ACL은 폴더, 파일 등에 대한 사용자나 그룹의 권한을 세밀하게 관리하며, 네트워크 ACL은 트래픽을 제어하여 네트워크 보안을 강화합니다. 이러한 ACL을 통해 조직은 보안 정책을 효과적으로 enforce하고, 무단 접근을 방지할 수 있습니다. ACL의 사용법과 구체적인 설정은 파일 시스템 및 네트워크 보안에서 매우 중요하며, 이는 시스템의 전반적인 보안 수준을 높이는 데 기여합니다.

 

 

---

계정관리

 

사용 및 액세스 추적

 

계정 관리(Accounting)

보안의 세 가지 A 중 마지막인 **계정 관리(Accounting)**는 사용자 활동을 추적하고 기록하는 과정입니다. 계정 관리는 주로 감사(Audit)와 밀접하게 연관되어 있으며, 시스템의 사용 및 활동을 모니터링하고 로그를 검토하여 이상 징후를 식별하는 데 중점을 둡니다.

 

계정 관리의 주요 요소

계정 관리 시스템은 여러 가지 활동을 추적합니다. 이는 사용되는 시스템의 목적과 의도에 따라 다릅니다.

1. TACACS+
   • 인증된 사용자: 누가 시스템에 접근했는지 추적.
   • 접근한 시스템: 사용자가 어떤 시스템에 접근했는지 추적.
   • 실행한 명령어: 세션 중에 실행된 명령어를 추적.
   • 작업 로그: 구성 변경, 재부팅 등의 시스템 작업 기록.
   Cisco의 TACACS+는 네트워크 장비에 대한 접근 제어 및 관리에 주로 사용됩니다. 이는 사용자가 네트워크 장비에서 수행한 작업을 세부적으로 기록합니다.

 

1. RADIUS
   • 세션 시간: 세션의 시작 및 종료 시간 기록.
   • 클라이언트 위치: 사용자가 접속한 위치 추적.
   • 리소스 사용량: 세션 중 사용된 대역폭, 데이터 전송량 등의 리소스 사용량 추적.
   RADIUS는 네트워크 접근 제어에 주로 사용되며, ISP에서 청구 목적으로도 사용됩니다. 이는 사용자 세션의 지속 시간과 데이터 사용량을 기록하지만, 세부적인 활동 내용은 포함하지 않습니다.

계정 관리의 작동 방식

계정 관리 시스템은 일반적으로 다음과 같은 과정을 거칩니다:

1. 로그 수집: 시스템이 사용자 활동을 기록합니다.
2. 로그 전송: 기록된 로그를 중앙 서버로 전송합니다.
3. 로그 저장: 중앙 서버가 로그를 저장합니다.
4. 로그 분석: 감사자가 로그를 검토하여 이상 징후를 식별합니다.

예를 들어, RADIUS 계정 관리는 네트워크 액세스 서버(NAS)가 계정 관리 서버로 세션 시작 및 종료, 정기적인 세션 통계 정보를 포함한 계정 관리 메시지를 전송하는 방식으로 이루어집니다.

 

계정 관리의 목적

계정 관리는 다양한 목적을 위해 사용됩니다:

• 보안 감사: 시스템 사용 기록을 검토하여 보안 침해나 이상 징후를 식별합니다.
• 리소스 관리: 시스템 리소스 사용량을 모니터링하고 관리합니다.
• 청구: ISP나 서비스 제공자가 사용자에게 청구할 사용량을 추적합니다.
• 정책 시행: 조직의 보안 정책을 enforce하고, 규정 준수를 보장합니다.

 

계정 관리의 중요성

계정 관리는 다음과 같은 이유로 중요합니다:

• 보안 강화: 시스템 사용 기록을 통해 보안 침해를 조기에 발견하고 대응할 수 있습니다.
• 규정 준수: 규제 요구 사항을 준수하고, 감사 요구 사항을 충족할 수 있습니다.
• 효율적인 리소스 사용: 시스템 리소스 사용량을 모니터링하고 최적화할 수 있습니다.

 

계정 관리는 시스템의 사용을 추적하고 기록하는 중요한 보안 활동입니다. 이는 사용자가 시스템에 접근하여 수행한 작업을 기록하고, 이러한 기록을 검토하여 이상 징후를 식별하는 과정을 포함합니다. TACACS+와 RADIUS는 각각 네트워크 장비와 네트워크 접근 제어에 대한 계정 관리 기능을 제공하며, 이는 보안 감사, 리소스 관리, 청구, 정책 시행 등의 목적으로 사용됩니다. 계정 관리는 조직의 전반적인 보안 태세를 강화하고, 규정 준수 및 효율적인 시스템 운영을 지원합니다.

 

 

 

 

반응형