[계정/권한 관리] freeIPA - HBAC, Sudo 통제 설정

2024.02.06 - [분류 전체보기] - [계정/권한 관리] freeIPA - IPA Client 설치 및 연동하기

본 글은 freeIPA 설치 후 초기 설정 방법에 대한 하나의 예시가 될 것이다.

여러 기능이 있는 freeIPA지만, 본글에서는 HBAC, Sudo 기능만 사용한다.

0. 들어가기에 앞서

클라이언트 설치 후 sssd 서비스 실행 시 Identify > Hosts에 Client 서버가 있어야 한다.

freeIPA는 호스트단위로 접근을 제어 한다. 이를 Host-based Access Control(이하 HBAC)이라 한다.

좀 더 자세히 설명하면 Access Control 정책 설정 시 아래의 Category를 조합하여 정책을 설정하고 동작한다.

호스트 (또는 호스트 그룹) : 서버
사용자 (또는 사용자 그룹) : 서버 계정
서비스 (또는 서비스 그룹) : ssh, ftp, http 등

즉, '어느 Host에 어느 User가 어떤 Service에 접근 허용 한다.'로 이해 하면 쉽다.

User Options

IPA Server > Configration 메뉴 진입

본인 환경이나 사이트에 맞게 설정

Default users group : 생성한 계정의 그룹명, 리눅스 내에서도 해당 그룹으로 표기된다.
Home directory base : 홈 디렉토리 경로, 필자의 경우 idM으로 생성한 계정은 특정 폴더 내에서 생성되게 끔 설정하였다. "/home/ipauser" 폴더에 홈폴더를 생성하기 위해 사전에 각 Client서버에 "/home/ipauser"를 생성해주어야 한다.
Default shell : 사용하기 편하게 리눅스와 동일한 /bin/bash를 선택하였다.

HBAC 설정

Policy > Host Base Access Control > HBAC Rules 메뉴에 진입

우측에 ADD 버튼을 클릭 후 Rule name 기재 후 Add and Edit 클릭

Who(User), Accessing(Server), Via Service(Service)를 선택 후 저장

위에서 설명했듯이 서버별로 HBAC Rule을 등록하는 것을 권장한다.
Via Service : 대부분 특별한 것이 없다면 ssh 및 그를 통한 su, sudo를 제어할 목적이기 때문에 서비스에는 ssh, sudo (필요에 따라서 su) 까지만 포함하는 것을 권장한다.
Accessing : 서버별로 접근 가능한 사람(또는 그룹)을 지정하는 것을 권장
- 서버 역할에 따라서 웹서버가 여러대 있다면 웹서버 호스트그룹을 생성하여 그룹으로 관리하는 것이 편리하다.
Who : Accessing에서 추가한 서버(또는 그룹)에 접근할 계정을 등록한다
- 조직이 큰 경우 동일 직무의 사람이 여러명이라면 유저그룹으로 관리하는 것이 편리하다.
- 유저(계정) 추가 시 Identify > Active users > 계정 클릭 > HBAC Rules에서 확인된다.
유저그룹+호스트그룹 으로 룰을 관리가 편리하지만, 의도치 않게 너무 넓은 범위로 접근을 제어하게 될 수 있으니 주의 해야 한다.
- 조직이 크고 관리 서버가 많다면 역할에 따른 유저그룹 + 용도별 호스트그룹으로 관리하면 편리하다 (=RBAC)

필요에 따라 Service별 제어를 더 하고 싶거나, 제어하고 싶은 Service가 목록에 없다면 HBAC Service, HBAC Service Group에서 추가하여 사용하면 된다.

Sudo 설정

Sudo Commands → Sudo Command Groups → Sudo Rules 순으로 설정하면 된다.
Sudo Commands : Sudo로 허용할 커맨드
Sudo Command Group : 용도별 Command를 묶는 단위
유저+서버+커맨드(그룹) 으로 설정하여 "어느 유저"가 "어느 서버"에 "어느 Sudo 명령어"을 허용 한다 로 설정

Policy > Sudo > Sudo Commands 메뉴 진입

+ADD 버튼을 통해 Sudo로 제어하고 싶은 명령어를 등록한다.

주의할 점은 명령어의 실제 위치를 기재 해야 한다.
- ls -> /bin/ls, find -> /bin/find 등
- 실제 위치는 "which 명령어"로 확인하면 된다.
- 기본적으로 관리자 외 일반유저는 조회용 명령어만 허용해도 충분하다.
Sudo Commands가 많으면 이후 Sudo Rule 추가 시 번거로우므로 Sudo Command Roles를 통해 그룹화 해야 한다.

Sudo > Sudo Roles 진입 후 +Add 한다.

Who(User), Access this host(Server), Run Commands(Command)를 설정한다.

Who(계정)은 유저그룹으로 관리하는 것이 편리하다.
- 모든 유저가 사용 가능한 Sudo > ipausers User group 추가
- 웹서비스 관리자가 사용 가능한 Sudo > web-admins User group 추가
- FTP 서비스 관리자가 사용 가능한 Sudo > ftp-admins User group 추가
- (web-admins, ftp-admins 유저 그룹은 사전에 만들었다고 가정한 예시이다.)
필자의 경우는 모든 사용자가 가능한 Sudo Command(조회용)만 등록하고 타 역할은 필요 시 su 권한 신청 후 root를 취득하여 작업하는 것으로 통제한다.
- 모든 사용자는 기본적으로 "ipausers"라는 유저 그룹에 포함되기 때문에 Identify > Groups > User Groups 에서 ipausers 그룹 상세 페이지 > Sudo Rules 확인 시 해당 Sudo role이 포함되어 있는것을 확인 할 수 있다.
- ipausers에 포함된 모든 유저(계정)은 해당 Sudo Command를 사용 할 수 있다.

Access this host : 해당 Sudo Commands를 허용할 서버를 지정한다.
- 범용 Sudo Commands 는 Any Host로 운영이 가능하다.
AS Whom은 Sudo 실행 시 사용할 계정이지만, 별도로 설정할 필요는 없어 보인다.

적용 정책을 Client서버에 즉시 적용하기

#IPA Client 서버는 sssd 데몬을 통해 IPA Server로 부터 정책을 받아온다.

#받아온 정책은 일정주기 동안 memcache에서 저장되어 사용된다. 그래서 memcache에 이미 정책이 있는 계정은 IPA Server에서 신규 정책을 설정해도 IPA Client는 memcache 저장되어 있는 정책을 우선 사용하기 때문에 바로 반영 되지 않는다.

[root@vm-k8s-master ~]# sss_cache -R
[root@vm-k8s-master ~]# tail -f /var/log/sssd/sssd_nicednb.local.log
(2023-12-20  9:48:18): [be[nicednb.local]] [ipa_sudo_fetch_rules_done] (0x0040): Received 1 sudo rules
(2023-12-20  9:48:18): [be[nicednb.local]] [ipa_sudo_fetch_cmdgroups_done] (0x0040): Received 2 sudo command groups
(2023-12-20  9:48:18): [be[nicednb.local]] [ipa_sudo_fetch_cmds_done] (0x0040): Received 6 sudo commands

sss_cache 명령어를 통해 IPA Client에서 사용하는 캐시를 초기화 할 수 있다.
"-R" 옵션은 모든 정책을 초기화 한다.
유저별 정책 초기화, 계정정보 초기화, sudo권한 초기화 등 여러 옵션이 있으며, 자세한 내용은 man sss_cache 참고

저작자표시 비영리

이뫼장의 유익한 까망화면