Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

2.4. 2일차 작업

Day 2 운영에는 호스트, 프로젝트, 환경 수준 Sustainment를 포함한 Cluster Health and Scaling Checks가 포함됩니다. 구성 및 보안 드리프트를 지속적으로 분석해야 합니다.

2.4.1. RBAC 고려 사항
링크 복사

관리자는 자동화 컨트롤러에 빌드된 RBAC(역할 기반 액세스 제어)를 사용하여 서버 인벤토리, 조직 등에 대한 액세스 권한을 위임할 수 있습니다. 관리자는 또한 다양한 인증 정보 관리를 중앙 집중화하여 최종 사용자가 해당 시크릿을 최종 사용자에게 노출하지 않고도 필요한 시크릿을 활용하도록 할 수 있습니다. 컨트롤러는 RBAC 제어를 통해 보안을 강화하고 관리를 간소화할 수 있습니다.

RBAC는 사용자 또는 팀에 역할을 부여하는 방식에 해당합니다. RBAC는 특정 기능이 설정되는 "오브젝트"를 보거나 변경하거나 삭제할 수 있는 사람 또는 대상을 정확하게 정의하는 역할 측면에서 생각하는 것이 가장 쉽습니다.

자동화 컨트롤러의 RBAC 설계(역할, 리소스 및 사용자)와 관련하여 숙지해야 하는 몇 가지 주요 개념이 있습니다. 사용자는 역할의 멤버일 수 있으므로 해당 역할과 연결된 모든 리소스 또는 "하위" 역할과 연결된 리소스에 대한 특정 액세스 권한을 부여할 수 있습니다.

역할은 기본적으로 기능 컬렉션입니다. 사용자에게 이러한 기능과 컨트롤러의 리소스에 대한 액세스 권한은 할당된 역할 또는 역할 계층 구조를 통해 상속된 역할을 통해 부여됩니다.

역할은 기능 그룹을 사용자 그룹과 연결합니다. 모든 기능은 역할 내의 멤버십에서 파생됩니다. 사용자는 할당된 역할이나 역할 계층 구조를 통해 상속된 역할을 통해서만 기능을 받습니다. 역할의 모든 멤버는 해당 역할에 부여된 모든 기능을 수행할 수 있습니다. 역할은 조직 내에서 비교적 안정적이지만 사용자와 기능은 둘 다 다양하고 빠르게 변경될 수 있습니다. 사용자는 다수의 역할을 가질 수 있습니다.

역할 계층 구조, 액세스 상속, 역할, 권한, 가상 사용자 생성 등에 대한 자세한 내용은 역할 기반 액세스 제어를 참조하십시오.

다음은 역할 및 리소스 권한이 있는 조직의 예입니다.

그림 2.3. 자동화 컨트롤러 내의 RBAC 역할 범위

역할 및 리소스 권한이 있는 조직의 예에 대한 참조 아키텍처입니다.

사용자 액세스는 특정 사용자에게 권한을 개별적으로 할당하는 대신 시스템 오브젝트(사용자, 그룹, 네임스페이스)에 대한 권한 관리를 기반으로 합니다. 생성한 그룹에 권한을 할당할 수 있습니다. 그런 다음 사용자를 이러한 그룹에 할당할 수 있습니다. 즉, 그룹의 각 사용자에게 해당 그룹에 할당된 권한이 있습니다.

Automation Hub에서 생성된 그룹은 내부 컬렉션 관리, 사용자 액세스 구성, 액세스 권한을 사용하여 그룹에 대한 리포지토리 관리를 담당하는 시스템 관리자부터 Automation Hub에 내부적으로 개발된 콘텐츠를 구성하고 업로드할 수 있는 액세스 권한을 갖는 그룹에 이르기까지 다양합니다. 자세한 내용은 일관성을 위한 자동화 허브 권한을 참조하십시오.

프라이빗 자동화 허브의 추가 잠금을 위해 보기 전용 액세스를 활성화할 수 있습니다. 보기 전용 액세스를 활성화하면 사용자가 로그인할 필요 없이 개인 자동화 허브의 컬렉션 또는 네임스페이스를 볼 수 있는 액세스 권한을 부여할 수 있습니다. 보기 전용 액세스를 사용하면 개인 자동화 허브에서 모든 항목을 편집할 수 있는 권한 없이 소스 코드를 보거나 다운로드할 수 있는 기능을 제한하면서 권한이 없는 사용자와 콘텐츠를 공유할 수 있습니다. Red Hat Ansible Automation Platform 설치 프로그램에 있는 인벤토리 파일을 편집하여 프라이빗 자동화 허브에 대한 보기 전용 액세스를 활성화합니다.

2.4.2. 업데이트 및 업그레이드
링크 복사

모든 업그레이드에서 현재 업그레이드 중인 대상 버전과 주요 버전의 차이가 두 버전 이하여야 합니다. 예를 들어 자동화 컨트롤러 4.3으로 업그레이드하려면 버전 3.8.x 또는 이전 버전에서 직접 업그레이드 경로가 없기 때문에 먼저 버전 4.1.x에 있어야 합니다. 자세한 내용은 Ansible Automation Platform 업그레이드를 참조하십시오. 자동화 컨트롤러 4.3을 실행하려면 Ansible 2.12 이상도 있어야 합니다.

2.4.2.1. 자동화 컨트롤러 STIG 고려 사항
링크 복사

자동화 컨트롤러는 조직 정책에 지정된 기간 내에 보안 관련 소프트웨어 업데이트를 설치하고 시스템 및 해당 조직 자산의 무결성 및 기밀성을 유지하는 데 필요한 보안 프로필을 설치해야 합니다.

소프트웨어 애플리케이션의 보안 결함은 매일 발견됩니다. Red Hat은 새로 발견된 보안 취약점을 해결하기 위해 지속적으로 자동화 컨트롤러를 업데이트하고 패치합니다. 조직(조직의 계약자 포함)은 보안 관련 소프트웨어 업데이트(예: 패치, 서비스 팩, 핫 수정)를 즉시 설치해야 합니다. 보안 평가, 지속적인 모니터링, 사고 대응 활동 또는 정보 시스템 오류 처리 중에 발견된 결함도 신속하게 처리해야 합니다.

각 자동화 컨트롤러 호스트에 대한 시스템 관리자로 다음을 수행합니다.

  1. DNF 자동 타이머의 상태를 검사합니다.

    systemctl status dnf-automatic.timer

  2. Active: active 가 출력에 포함되어 있지 않은 경우 검색입니다.

  3. DNF 자동 구성을 검사합니다.

    grep apply_updates /etc/dnf/automatic.conf

  4. apply_updates = yes 가 표시되지 않으면 검색입니다.

  5. DNF 자동 설치 및 활성화:

    dnf-automatic (설치 실행) systemctl enable --now dnf-automatic.timer

  6. /etc/dnf/automatic.conf 를 수정하고 apply_updates = yes 를 설정합니다.

모든 자동화 컨트롤러 nginx 프런트 엔드 웹 서버 파일은 프로덕션 웹 서버의 일부가 되기 전에 무결성(예: 체크섬 및 해시)이 있는지 확인해야 합니다. 웹 서버에 패치, 업그레이드, 인증서 등이 추가되는지 확인하는 것은 파일 검증 및 정보 조작을 위해서는 파일 생산자와 변경되지 않습니다. 자동화 컨트롤러 nginx 웹 서버 호스트에는 설치 전에 파일이 유효한지 확인하는 메커니즘이 있어야 합니다.

시스템 관리자로서 각 자동화 컨트롤러 nginx 웹 서버 호스트에 대해 다음을 수행합니다.

  1. 자동화 컨트롤러 nginx 웹 서버 호스트 파일의 무결성을 확인합니다.

    AIDE --check

  2. AIDE(Advanced Intrusion Detection Environment) 데이터베이스의 이전에 예약된 체크섬에 대해 표시된 체크섬을 확인합니다.
  3. 이전 체크섬에 대해 무단 또는 설명되지 않은 변경 사항이 있는 경우 이를 찾는 것입니다.

시스템 관리자로서 각 자동화 컨트롤러 nginx 웹 서버 호스트에 대해 다음을 수행합니다.

  1. 기존을 확인하거나 AIDE를 설치합니다.

    yum install -y aide

  2. 각 자동화 컨트롤러 nginx 웹 서버 호스트의 초기 설치 직후 AIDE 데이터베이스를 생성하거나 업데이트합니다.

    aide --init && mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

  3. AIDE 데이터베이스를 업데이트하여 호스트에 대해 예상되는 변경 사항을 수락합니다.

    aide --update

  4. 출력에서 AIDE 데이터베이스에 대한 체크섬을 제공합니다. 보호된 위치에 저장합니다.

모든 자동화 컨트롤러 nginx 웹 서버 계정은 설치된 기능(예: 툴, 유틸리티, 특정 서비스 등)에서 사용하지 않아야 하며 웹 서버 기능이 제거될 때 삭제해야 합니다. 웹 서버 계정을 사용하지 않는 경우 웹 서버를 제거할 때 삭제해야 합니다. 이는 계정이 시간이 지남에 따라 오래되고 경향이 있지 않기 때문입니다. 또한 계정을 사용하지 않는 경우 동일한 이유로 계정을 만들 수 없습니다. 두 경우 모두 웹 서버 악용 기회를 생성합니다.

기능이 설치되지 않은 경우에도 문서, 샘플 코드 예제 애플리케이션, 튜토리얼, 유틸리티 및 서비스와 같은 웹 서버 기능에 사용되는 계정이 웹 서버에 악용할 수 있는 위험이 됩니다. 이러한 계정은 비활성화되고 정기적인 사용을 통해 모니터링되지 않으며 계정의 암호는 생성 또는 업데이트되지 않습니다. 공격자는 이러한 계정을 사용하여 웹 서버에 액세스하고 계정 권한을 평가하는 방법을 조사할 수 있습니다.

설치되지 않은 모든 자동화 컨트롤러 nginx 웹 서버 기능에 사용되는 계정을 생성해야 하며 이러한 기능이 제거될 때 삭제해야 합니다.

각 자동화 컨트롤러 nginx 웹 서버에 대한 시스템 관리자로 다음을 수행합니다.

  1. /etc/passwd 에서 nginx 사용자를 검사합니다.

  2. 명령을 사용하여 단일 사용자 nginx가 있는지 확인합니다.

    [ grep -c nginx /etc/passwd == 1 ] || echo FAILED

  3. FAILED 가 표시되면 이는 검색입니다.

각 자동화 컨트롤러 nginx 웹 서버에 대한 시스템 관리자로 다음을 수행합니다.

  1. /etc/passwd에 nginx 사용자가 없는 경우 자동화 컨트롤러 다시 설치
  2. /etc/passwd 에 열거된 모든 사용자를 검토하고 Red Hat Enterprise Linux 또는 자동화 컨트롤러 및/또는 조직에서 허용하지 않는 모든 사용자를 제거합니다.

자동화 컨트롤러 nginx 웹 서버는 업데이트 가용성에서 조직적으로 식별된 기간 내에 권한 있는 소스에서 보안 관련 소프트웨어 업데이트를 확인하고 설치하도록 구성되어 있습니다. 기본적으로 이 기간은 24시간마다 수행됩니다.

각 자동화 컨트롤러 nginx 웹 서버 호스트에 대한 시스템 관리자로 다음을 수행합니다.

  1. 권한 있는 시스템 업데이트에 대해 조직적으로 정의된 소스에서 업데이트를 수신하도록 시스템이 구성되었는지 확인합니다.

    yum -v repolist

  2. 각 URL이 유효하지 않고 조직적으로 정의된 요구 사항과 일치하는 경우 이를 찾는 것입니다.
  3. 각 리포지토리가 조직적으로 정의된 요구 사항에 따라 활성화되지 않은 경우 이를 찾는 것입니다.
  4. 시스템에서 최소 30일마다 이 소스에서 시스템 업데이트를 자동으로 수신 및 적용하거나 최소 30일마다 수동으로 업데이트를 수신하고 적용하도록 구성되지 않은 경우 이는 발견입니다.

시스템 관리자로서 각 자동화 컨트롤러 nginx 웹 서버 호스트에 대해 다음을 수행합니다.

  1. 조직적으로 정의된 요구 사항에 따라 업데이트 리포지토리를 구성하거나 기본 운영 체제의 Red Hat 업데이트 리포지토리를 구독합니다.

  2. 이러한 리포지토리에서 업데이트를 실행합니다.

    $ yum update -y

  3. 다음 중 하나를 수행합니다.

    1. 30일마다 또는 조직적으로 정의된 정책에 따라 업데이트 일정을 예약합니다.

      $ yum install -y dnf-automatic && sed -i '/apply_updates/s/no/no/yes/' /etc/dnf/automatic.conf && sed -i '/On Cryostat/s/^On Cryostat\s*=./On Cryostat=-1-* 6:00/' /usr/lib/systemd/system/dnf-automatic.timer && systemctl enable --now dnf-automatic.timer

    2. 최소 30일마다 또는 조직적으로 정의된 정책에 따라 수동 업데이트를 예약하십시오.
  4. 자동화 컨트롤러 nginx 웹 서버 호스트를 다시 시작합니다.

2.4.2.2. 재해 복구 및 운영 연속성
링크 복사

Ansible Automation Platform을 정기적으로 백업하는 것은 재해 복구 계획에서 중요한 부분입니다. 백업 및 복원은 설치 프로그램을 사용하여 수행되므로 이 문서의 앞부분에서 설명하는 전용 설치 호스트에서 이러한 작업을 수행해야 합니다. 이러한 작업을 수행하는 방법에 대한 자세한 내용은 자동화 컨트롤러 설명서의 백업 및 복원 섹션을 참조하십시오.

백업의 중요한 측면은 데이터베이스에 저장된 자격 증명을 해독하는 데 사용되는 시크릿 키와 데이터베이스 복사본을 포함하므로 백업 파일을 안전한 암호화된 위치에 저장해야 합니다. 즉, 엔드포인트 자격 증명에 대한 액세스가 올바르게 보호됩니다. 백업에 대한 액세스는 자동화 컨트롤러 및 전용 설치 호스트에 대한 루트 쉘 액세스 권한이 있는 Ansible Automation Platform 관리자에게만 제한되어야 합니다.

Ansible Automation Platform 관리자가 Ansible Automation Platform 환경을 백업해야 하는 두 가지 주요 이유는 다음과 같습니다.

  • Ansible Automation Platform 환경에서 데이터 사본을 저장하려면 필요한 경우 복원할 수 있습니다.
  • 새 Ansible Automation Platform 클러스터를 생성하거나 업그레이드를 준비 중인 경우 백업을 사용하여 환경을 다른 서버 세트로 복원하려면 다음을 수행합니다.

모든 경우에 권장되는 안전한 프로세스는 항상 동일한 버전의 PostgreSQL 및 Ansible Automation Platform을 사용하여 환경을 백업하고 복원하는 것입니다.

시스템에서 중복을 사용하는 것이 좋습니다. 시크릿 시스템이 다운되면 자동화 컨트롤러에서 정보를 가져올 수 없으며 서비스가 복원되면 복구할 수 있는 방식으로 실패할 수 있습니다. SECRET_KEY 자동화 컨트롤러가 손상되어 다시 생성해야 하는 경우 자동화 컨트롤러 백업 및 복원 툴과 비슷하게 작동하는 설치 프로그램에서 툴을 실행할 수 있습니다.

새 시크릿 키를 생성하려면 다음 단계를 수행합니다.

  1. 다른 작업을 수행하기 전에 Ansible Automation Platform 데이터베이스를 백업하십시오! Backing Up 및 Restoring Controller 섹션에 설명된 절차를 따르십시오.
  2. 설치의 인벤토리(백업/복원를 실행하는 것과 동일한 인벤토리)를 사용하여 setup.sh -k 를 실행합니다.

이전 키의 백업 복사본은 /etc/tower/ 에 저장됩니다.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

Legal Notice

Theme

© 2026 Red Hat맨 위로 이동