강화 및 컴플라이언스

Ansible Automation Platform의 세 가지 설치 방법이 있습니다.

이 문서에서는 처음 두 설치 방법(RPM 기반 또는 컨테이너 기반)을 사용하여 설치할 때 Ansible Automation Platform 강화에 대한 지침을 제공합니다. 이 문서는 RPM 기반 설치 프로그램이 향후 릴리스에서 더 이상 사용되지 않으므로 새 배포에 컨테이너 기반 설치 방법을 사용하는 것이 좋습니다.

자세한 내용은 더 이상 사용되지 않는 기능을 참조하십시오.

Operator 기반 배포는 이 문서에 설명되지 않습니다.

Ansible Automation Platform은 자동화 컨트롤러, 플랫폼 게이트웨이, 자동화 허브, 이벤트 기반 Ansible 컨트롤러를 포함하여 서로 연결할 수 있는 별도의 구성 요소로 구성된 모듈식 플랫폼입니다.

테스트된 배포 모델에 정의된 문서화된 배포 참조 아키텍처 중 하나를 기반으로 Ansible Automation Platform 2.5를 설치합니다. 엔터프라이즈 조직은 최고 수준의 가동 시간, 성능 및 지속적인 확장성을 보장하기 위해 프로덕션 배포를 위해 엔터프라이즈 참조 아키텍처 중 하나를 사용해야 합니다. 리소스 제한에 해당하는 조직 또는 배포는 "개발" 참조 아키텍처를 사용할 수 있습니다. 테스트된 배포 모델 문서를 검토하여 요구 사항에 가장 적합한 참조 아키텍처를 확인합니다. 선택한 참조 아키텍처에는 아키텍처 다이어그램, Red Hat Enterprise Linux 서버 수, 배포에 사용되는 네트워크 포트 및 프로토콜, 엔터프라이즈 아키텍처에 대한 로드 밸런서 정보와 같은 계획 정보가 포함됩니다.

다양한 인프라 참조 아키텍처 및 다양한 환경 구성에 Ansible Automation Platform을 설치할 수 있습니다. Red Hat은 게시된 참조 아키텍처 외부에서 아키텍처를 완전히 테스트하지 않습니다. Red Hat은 테스트된 참조 아키텍처를 모든 신규 배포에 사용할 것을 권장하며 최소 요구 사항을 충족하는 배포에 대해 상업적으로 합리적인 지원을 제공합니다.

다음 다이어그램은 테스트된 컨테이너 엔터프라이즈 아키텍처입니다.

그림 2.1. 참조 아키텍처 개요

Ansible Automation Platform과 관련된 방화벽 또는 클라우드 네트워크 보안 그룹 구성을 계획할 때 방화벽 또는 보안 그룹에서 열어야 하는 네트워크 포트를 이해하기 위해 테스트 배포 모델에서 선택한 토폴로지의 "네트워크 포트" 섹션을 참조하십시오.

인터넷에 연결된 시스템의 경우 설치 계획의 네트워크 및 프로토콜 섹션에서는 Red Hat 자동화 허브, Ansible Automation Platform용 Insights, Ansible Galaxy, registry.redhat.io 컨테이너 이미지 레지스트리 등과 같이 Ansible Automation Platform을 사용하도록 구성할 수 있는 서비스에 대한 발신 트래픽 요구 사항을 정의합니다.

Ansible Automation Platform 구성 요소에서 사용하는 포트에 대한 액세스를 보호된 네트워크 및 클라이언트에 제한합니다. 다음과 같은 제한 사항이 권장됩니다.

Red Hat Ansible Automation Platform은 인증 정보를 사용하여 머신에 대한 작업에 대한 요청을 인증하고, 인벤토리 소스와 동기화하고, 버전 제어 시스템에서 프로젝트 콘텐츠를 가져옵니다.

자동화 컨트롤러는 다음 세 가지 보안 세트를 관리합니다.

인증 정보를 손상시키지 않도록 보호하기 위해 권한 있는 액세스 또는 인증 정보 관리 솔루션을 구현하는 것이 좋습니다. 조직은 사용을 감사하고 추가 프로그래밍 방식의 제어, 액세스 및 권한 에스컬레이션을 제공해야 합니다.

자동화 인증 정보가 고유하고 자동화 컨트롤러에만 저장되도록 하여 자동화 인증 정보를 추가로 보호할 수 있습니다. OpenSSH와 같은 서비스는 특정 주소의 연결에서만 인증 정보를 허용하도록 구성할 수 있습니다. 시스템 관리자가 서버에 로그인하는 것과 다른 인증 정보를 사용하여 자동화합니다. 가능한 경우 직접 액세스를 제한해야 하지만 재해 복구 또는 기타 임시 관리에 사용할 수 있으므로 감사가 더 쉬워집니다.

자동화 작업이 서로 다른 수준에서 시스템에 액세스해야 할 수 있습니다. 예를 들어 상위 수준의 자동화 부분은 애플리케이션을 배포하는 반면, 낮은 수준의 시스템 자동화를 통해 패치를 적용하고 보안 기준 검사를 수행할 수 있습니다. 각 자동화 부분에 서로 다른 키 또는 인증 정보를 사용하면 하나의 주요 취약점이 미치는 영향을 최소화합니다. 또한 기준 감사를 쉽게 수행할 수 있습니다.

Ansible Automation Platform 환경에서 고려해야 할 두 가지 유형의 사용자 계정이 있습니다.

가시성 및 분석은 Enterprise Security 및 Zero Trust Architecture의 중요한 요소입니다. 로깅은 작업을 캡처하고 감사를 전달하는 핵심입니다. Red Hat Enterprise Linux 보안 강화 가이드의 시스템 감사 섹션에 설명된 기본 제공 감사 지원을 사용하여 로깅 및 감사를 관리할 수 있습니다. Ansible Automation Platform의 기본 제공 로깅 및 활동 스트림은 감사 목적으로 Red Hat Ansible Automation Platform 및 자동화 로그 내의 모든 변경 사항을 기록합니다. 자세한 내용은 자동화 실행 구성의 로깅 및 집계 섹션에서 확인할 수 있습니다.

이 가이드에서는 로컬 시스템에서 검토하지 않고 로깅 및 감사를 중앙에서 수집하도록 Ansible Automation Platform 및 기본 Red Hat Enterprise Linux 시스템을 구성하는 것이 좋습니다. Ansible Automation Platform은 외부 로깅을 사용하여 Ansible Automation Platform 서버 내의 여러 구성 요소에서 로그 레코드를 컴파일하도록 구성해야 합니다. 발생하는 이벤트는 정확한 법의학 분석을 수행하는 것과 관련이 있어야합니다. 즉, Ansible Automation Platform 서버는 로깅 수집기 서비스와 Ansible Automation Platform의 대상에서도 사용하는 NTP 서버로 구성해야 합니다. 상관관계는 특정 산업 허용 요구사항을 충족해야 합니다. 즉, 로그된 다양한 이벤트의 타임스탬프가 x 초보다 크게 달라지지 않아야 한다는 다양한 요구 사항이 있을 수 있습니다. 이 기능은 외부 로깅 서비스에서 사용할 수 있어야 합니다.

로깅의 또 다른 중요한 기능은 암호화를 사용하여 로그 툴의 무결성을 보호하는 기능입니다. 로그 데이터에는 정보 시스템 활동을 성공적으로 기록하는 데 필요한 모든 정보(예: 로그 레코드, 로그 설정 및 로그 보고서)가 포함됩니다. 공격자는 로그 도구를 교체하거나 기존 도구에 코드를 삽입하여 로그에서 시스템 활동을 숨기거나 지우는 것이 일반적입니다. 이 위험을 해결하려면 로그 도구가 수정, 조작 또는 교체되었는지 확인할 수 있도록 로그 툴을 암호화 방식으로 서명해야 합니다. 예를 들어 로그 툴이 수정, 조작 또는 교체되지 않았는지 확인하는 한 가지 방법은 툴 파일에 대해 체크섬 해시를 사용하는 것입니다. 이렇게 하면 툴의 무결성이 손상되지 않습니다.

Ansible Automation Platform은 다음과 같은 일반적인 사용 사례에 NIST Cybersecurity Framework를 적용하여 보안 정책 요구 사항을 충족하는 데 사용해야 합니다.

이 작업은 보안 보안 프레임 워크의 5 단계로 수행 할 수 있습니다.

Ansible Automation Platform의 보안은 기본 Red Hat Enterprise Linux 서버의 구성에 부분적으로 의존합니다. 이러한 이유로 각 Ansible Automation Platform 구성 요소에 대한 기본 Red Hat Enterprise Linux 호스트는 Red Hat Enterprise Linux 8의 보안 강화 또는 Red Hat Enterprise Linux 9의 보안 강화에 따라 설치 및 구성해야 합니다(운영 체제 사용에 따라). 및 모든 보안 프로필 요구 사항(CIS(Internet Security ), STIG, HIPAA( Health Insurance Portability and Accountability Act ) 및 조직에서 사용하는 조직). 이 문서에서는 모든 새로운 배포에 대해 Red Hat Enterprise Linux 9를 권장합니다. 컨테이너 기반 설치 방법을 사용하는 경우 Red Hat Enterprise Linux 9가 필요합니다.

Ansible Automation Platform 설치 프로그램은 자동화 컨트롤러와 같은 인프라 서버 중 하나 또는 Ansible Automation Platform 인프라 서버에 대한 SSH 액세스 권한이 있는 외부 시스템에서 실행할 수 있습니다. Ansible Automation Platform 설치 프로그램은 설치뿐만 아니라 백업 및 복원과 같은 2일차 작업뿐만 아니라 업그레이드에도 사용됩니다. 이 가이드에서는 여기에서 설치 호스트라는 전용 외부 서버에서 설치 및 Day-two 작업을 수행할 것을 권장합니다. 이렇게 하면 이러한 기능을 실행하기 위해 인프라 서버 중 하나에 로그인할 필요가 없습니다. 설치 호스트는 Ansible Automation Platform 관리에만 사용해야 하며 다른 서비스 또는 소프트웨어를 실행하지 않아야 합니다.

설치 호스트는 Red Hat Enterprise Linux의 보안 강화 및 조직 관련 보안 프로필 요구 사항(CIS, STIG 등)에 따라 설치 및 구성된 Red Hat Enterprise Linux 서버여야 합니다. 설치 계획에 설명된 대로 Ansible Automation Platform 설치 프로그램을 가져오고 Red Hat Ansible Automation Platform 설치 프로그램 인벤토리 파일 편집에 설명된 대로 설치 프로그램 인벤토리 파일을 생성합니다. 이 인벤토리 파일은 업그레이드, 인프라 구성 요소 추가, 설치 프로그램에서 Day-two 작업 등에 사용되므로 향후 작동을 위해 설치 후 파일을 보존합니다.

설치 호스트에 대한 액세스는 Ansible Automation Platform 인프라 관리를 담당하는 인력으로만 제한되어야 합니다. 시간이 지남에 따라 설치 인벤토리(Ansible Automation Platform의 초기 로그인 인증 정보 포함), 사용자 제공 PKI 키 및 인증서, 백업 파일 등 중요한 정보가 포함됩니다. 인프라 관리 및 유지 관리에 필요한 경우 SSH를 통해 Ansible Automation Platform 인프라 서버에 로그인하는 데 설치 호스트를 사용해야 합니다.

설치 인벤토리 파일은 Ansible Automation Platform 인프라의 아키텍처를 정의하고 인프라 구성 요소의 초기 구성을 수정하는 데 사용할 수 있는 여러 변수를 제공합니다. 설치 프로그램 인벤토리에 대한 자세한 내용은 설치 프로그램 인벤토리 파일 정보를 참조하십시오.

다음 표에는 여러 보안 관련 변수와 RPM 기반 배포에 권장되는 값이 나열되어 있습니다.

다음 표에는 컨테이너 기반 배포에 대한 여러 보안 관련 변수와 권장 값이 나열되어 있습니다.

로드 밸런서가 여러 플랫폼 게이트웨이 앞에 사용되는 엔터프라이즈 아키텍처에서는 로드 밸런서에서 SSL 클라이언트 연결을 종료하거나 개별 AAP 서버로 전달할 수 있습니다. 로드 밸런서에서 SSL을 종료하는 경우 이 가이드에서는 트래픽을 로드 밸런서에서 개별 Ansible Automation Platform 서버로 다시 암호화할 것을 권장합니다. 이렇게 하면 엔드 투 엔드 암호화를 사용할 수 있습니다. 이 시나리오에서는 나열된 *_disable_https 변수가 기본값 false 로 설정됩니다.

기본적으로 Ansible Automation Platform은 플랫폼의 인프라 구성 요소에 대해 자체 서명된 PKI( Public Key Infrastructure ) 인증서를 생성합니다. 기존 PKI 인프라를 사용할 수 있는 경우 자동화 컨트롤러, 프라이빗 자동화 허브, 이벤트 기반 Ansible 컨트롤러 및 사후 데이터베이스 서버에 대한 인증서를 생성해야 합니다. 인증서를 확인하는 데 사용되는 CA 인증서와 함께 인증서 파일 및 관련 키 파일을 설치 프로그램 디렉터리에 복사합니다.

다음 인벤토리 변수를 사용하여 새 인증서로 인프라 구성 요소를 구성합니다.

로드 밸런서와 함께 여러 플랫폼 게이트웨이가 배포되면 gateway_tls_cert 및 gateway_tls_key 는 각 플랫폼 게이트웨이에서 공유합니다. 호스트 이름이 일치하지 않도록 하려면 인증서의 CN( 일반 이름 )이 로드 밸런서에서 사용하는 DNS FQDN과 일치해야 합니다. 조직 정책에 각 서비스에 대한 고유한 인증서가 필요한 경우 각 인증서에 로드 밸런싱 서비스에 사용되는 DNS FQDN과 일치하는 SAN( 주체 대체 이름 )이 필요합니다. 각 플랫폼 게이트웨이에 고유한 인증서와 키를 설치하려면 설치 인벤토리 파일의 인증서 및 키 변수를 [all:vars] 섹션 대신 호스트별 변수로 정의해야 합니다. 예를 들면 다음과 같습니다.

[automationgateway]
gateway0.example.com gateway_tls_cert=/path/to/cert0 gateway_tls_key=/path/to/key0
gateway1.example.com gateway_tls_cert=/path/to/cert1 gateway_tls_key=/path/to/key1

[automationcontroller]
controller0.example.com web_server_ssl_cert=/path/to/cert0 web_server_ssl_key=/path/to/key0
controller1.example.com web_server_ssl_cert=/path/to/cert1 web_server_ssl_key=/path/to/key1
controller2.example.com web_server_ssl_cert=/path/to/cert2 web_server_ssl_key=/path/to/key2

[automationhub]
hub0.example.com automationhub_ssl_cert=/path/to/cert0 automationhub_ssl_key=/path/to/key0
hub1.example.com automationhub_ssl_cert=/path/to/cert1 automationhub_ssl_key=/path/to/key1
hub2.example.com automationhub_ssl_cert=/path/to/cert2 automationhub_ssl_key=/path/to/key2

[automationgateway]
gateway0.example.com gateway_tls_cert=/path/to/cert0 gateway_tls_key=/path/to/key0
gateway1.example.com gateway_tls_cert=/path/to/cert1 gateway_tls_key=/path/to/key1

[automationcontroller]
controller0.example.com web_server_ssl_cert=/path/to/cert0 web_server_ssl_key=/path/to/key0
controller1.example.com web_server_ssl_cert=/path/to/cert1 web_server_ssl_key=/path/to/key1
controller2.example.com web_server_ssl_cert=/path/to/cert2 web_server_ssl_key=/path/to/key2

[automationhub]
hub0.example.com automationhub_ssl_cert=/path/to/cert0 automationhub_ssl_key=/path/to/key0
hub1.example.com automationhub_ssl_cert=/path/to/cert1 automationhub_ssl_key=/path/to/key1
hub2.example.com automationhub_ssl_cert=/path/to/cert2 automationhub_ssl_key=/path/to/key2

설치 인벤토리 파일에는 주로 Ansible Automation Platform에서 사용하는 초기 암호를 설정하는 데 사용되는 여러 중요한 변수가 포함되어 있으며 일반적으로 인벤토리 파일의 일반 텍스트로 유지됩니다. 이러한 변수를 무단으로 보지 못하도록 이러한 변수를 암호화된 Ansible 자격 증명 모음에 유지할 수 있습니다. 이렇게 하려면 설치 프로그램 디렉터리로 이동하여 자격 증명 모음 파일을 생성합니다.

새 Ansible 자격 증명 모음에 대한 암호를 입력하라는 메시지가 표시됩니다. 2일차 작업 및 백업 프로시저를 포함하여 자격 증명 모음 파일에 액세스해야 할 때마다 자격 증명 모음 암호를 손실하지 마십시오. 암호화된 암호 관리자에 저장하거나 암호를 안전하게 저장하기 위한 조직 정책에 따라 vault 암호를 보호할 수 있습니다.

중요한 변수를 자격 증명 모음에 추가합니다. 예를 들면 다음과 같습니다.

admin_password/controller_admin_password: <secure_controller_password>
pg_password/controller_pg_password: <secure_db_password>
automationhub_admin_password/hub_admin_password: <secure_hub_password>
automationhub_pg_password/hub_pg_password: <secure_hub_db_password>
automationedacontroller_admin_password/eda_admin_password: <secure_eda_password>
automationedacontroller_pg_password/eda_pg_password: <secure_eda_db_password>
-/gateway_admin_password: <secure_gateway_password>
-/gateway_pg_password:<secure_gateway_db_password>

admin_password/controller_admin_password: <secure_controller_password>
pg_password/controller_pg_password: <secure_db_password>
automationhub_admin_password/hub_admin_password: <secure_hub_password>
automationhub_pg_password/hub_pg_password: <secure_hub_db_password>
automationedacontroller_admin_password/eda_admin_password: <secure_eda_password>
automationedacontroller_pg_password/eda_pg_password: <secure_eda_db_password>
-/gateway_admin_password: <secure_gateway_password>
-/gateway_pg_password:<secure_gateway_db_password>

이러한 변수가 설치 인벤토리 파일에도 표시되지 않는지 확인합니다. 새 Ansible 자격 증명 모음을 설치 프로그램과 함께 사용하려면 ./setup.sh -e @vault.ymlEngine-listener--ask-vault-pass 명령으로 실행합니다.

대부분의 환경에서는 CIS Critical Security Controls, PCI/DSS( Payment Card Industry/Data Security Standard ), DISA STIG 또는 유사한 프로필과 같은 규정 준수 프로필의 요구 사항을 충족하기 위해 보안 제어가 적용된 Red Hat Enterprise Linux 시스템에 Ansible Automation Platform을 설치해야 할 수 있습니다. 이러한 환경에는 Ansible Automation Platform이 올바르게 실행되도록 수정해야 하는 특정 보안 제어 세트가 있습니다. 설치 전에 Ansible Automation Platform에 사용되는 Red Hat Enterprise Linux 서버에 규정 준수 프로필 제어를 적용한 다음 필요에 따라 다음 보안 제어를 수정합니다.

이러한 제어가 필요한 환경에서는 보안 감사자와의 제어를 포기합니다.

Red Hat Community of Practice는 Ansible Automation Platform 인프라 및 구성을 코드로 관리하기 위해 컬렉션을 통해 사용할 수 있는 자동화 콘텐츠 세트를 생성했습니다. 이를 통해 CaC( Configuration as Code )를 통해 플랫폼 자체를 자동화할 수 있습니다. 이 접근 방식의 많은 이점이 명확하지만 고려해야 할 보안 영향이 있습니다.

다음 Ansible 콘텐츠 컬렉션은 인프라를 코드 방법론으로 사용하여 Ansible Automation Platform 구성 요소를 관리하는 데 사용할 수 있으며, 모두 Ansible Automation Hub 에 있습니다.

많은 조직에서 CI/CD 플랫폼을 사용하여 파이프라인 또는 이러한 유형의 인프라를 관리하는 다른 방법을 구성합니다. 그러나 Ansible Automation Platform을 기본적으로 사용하면 Git 기반 리포지토리를 기본적으로 연결하도록 Webhook를 구성할 수 있습니다. 이러한 방식으로 Ansible은 Git 이벤트에 응답하여 작업 템플릿을 직접 트리거할 수 있습니다. 이렇게 하면 이 전체 프로세스에서 외부 CI 구성 요소가 필요하지 않으므로 공격 면적이 줄어듭니다.

이러한 사례를 통해 모든 인프라 및 구성을 버전 제어할 수 있습니다. Ansible Automation Platform에 동기화되기 전에 적절한 코드 품질 검사를 보장하기 위해 Git 모범 사례를 적용합니다. 관련 Git 모범 사례는 다음과 같습니다.

CAC는 또한 중요한 데이터를 리포지토리에 저장하거나 필요에 따라 개별적으로 자격 증명 모음 파일을 처리할 필요가 없는 외부 자격 증명 모음 시스템을 사용하는 것이 좋습니다. 이는 자동화 컨트롤러 자격 증명 및 이벤트 기반 Ansible 인증 정보를 소스 리포지토리에 커밋해서는 안 되는 일반 텍스트로 컬렉션 변수에 제공해야 하므로 소스 코드 리포지토리에 Ansible Automation Platform 구성을 저장할 때 특히 중요합니다. 외부 자격 증명 모음 시스템 사용에 대한 자세한 내용은 이 가이드의 외부 인증 정보 자격 증명 모음 고려 사항 섹션을 참조하십시오.

시스템 보안을 모니터링하고 대규모 로그 분석을 수행하는 데 필요한 중앙 집중식 로깅이 필요합니다. 미군 과 정부의 아이디어로 부터 시작된 CIA(Confidentiality, Integrity, Availability ) triad는 적절한 보안 시스템 개발 및 모범 사례의 기반이 되는 모델입니다. 중앙 집중식 로깅은 데이터 또는 시스템이 변조되었는지 확인하는 데 도움이 되는 무결성 측면 아래에 있습니다. 중앙 집중식 시스템에 로깅하면 단일 위치에서 모든 로그를 수집하여 여러 시스템에서 자동화 문제를 해결할 수 있으므로 문제를 쉽게 식별하고 추세를 분석하고, 특히 복잡한 Ansible Automation Platform 배포에서 서로 다른 서버의 이벤트를 연관시킬 수 있습니다. 그렇지 않으면 개별 머신을 수동으로 확인하는 데 시간이 걸리므로 보안 모범 사례를 충족하는 것 외에도 디버깅과 함께 이 기능이 중요합니다. 이를 통해 전체 시스템 상태, 안정성 및 잠재적인 보안 위협을 식별하는 데 도움이 됩니다. 로깅 구성 외에도 스토리지 용량으로 인한 로그 실패, 하드웨어 장애 및 고가용성 아키텍처를 고려해야 합니다.

다음과 같은 몇 가지 추가 이점이 있습니다.

로깅 수집기 서비스는 다음과 같은 모니터링 및 데이터 분석 시스템에서 작동합니다.

중앙 집중식 로깅을 위해 수집기 유형에 대한 로깅을 설정하려면 다음 단계를 따르십시오.

다음 단계에서는 LDAP 로깅을 활성화합니다.

LDAP에 대한 로깅을 활성화하려면 다음 절차를 사용하십시오.

다음 규정 준수 요구 사항의 몇 가지 예는 US DoD Security Technical Implementation Guide 에서 제공되지만 무결성 및 보안 모범 사례로 돌아갑니다.

자동화 컨트롤러는 수정 또는 거부를 방지하기 위해 독립적인 보호된 리포지토리에서 사용자 활동 로그를 수집할 수 있는 외부 로그 공급자를 사용해야 합니다. 외부 로깅을 사용하여 서버 내의 여러 구성 요소에서 로그 레코드를 컴파일하도록 자동화 컨트롤러를 구성해야 합니다. 정확한 법의학 분석을 수행하기 위해 발생하는 이벤트는 시간 상관관계여야 합니다. 또한 상관관계는 특정 허용 기준을 충족해야 합니다.

다음 단계에서는 보안 제어를 구현합니다.

자동화 컨트롤러는 로그 실패 시 로그 레코드 스토리지 용량을 할당하고 기본적으로 종료해야 합니다(사용은 재정의되지 않음). 시스템이 로그를 처리하지 못할 위험이 있는 경우 오류를 감지하여 작업을 수행하여 완화해야 합니다. 로그 처리 실패에는 소프트웨어/하드웨어 오류, 로그 캡처 메커니즘의 실패, 도달 또는 초과되는 로그 스토리지 용량이 포함됩니다. 오류가 발생하는 동안 애플리케이션 서버가 고가용성 시스템의 일부가 아닌 한 애플리케이션 서버를 종료하도록 구성해야 합니다. 가용성이 덮어쓰기 문제인 경우 로그 장애에 대한 응답으로 다른 승인된 작업은 다음과 같습니다.

자동화 컨트롤러에서 적절한 로그 레코드를 생성해야 합니다. 자동화 컨트롤러의 웹 서버는 문제 해결, 디버깅 및 법의 분석을 지원하기 위해 사용자 세션과 관련된 모든 세부 정보를 기록해야 합니다. 데이터 로깅 기능이 없으면 조직에서 이벤트 조사를 위한 중요한 감사 및 분석 도구가 손실됩니다.

각 자동화 컨트롤러 호스트에 대해 보안 제어를 시스템 관리자로 구현하려면 다음을 수행합니다.

자동화 컨트롤러의 로그 파일은 명시적으로 정의된 권한으로 액세스할 수 있어야 합니다. 자동화 컨트롤러 로그 파일의 기밀성을 유지하지 않으면 공격자는 더 많은 정보를 열거하여 에스컬레이션 또는 나중 이동을 활성화할 수 있는 시스템에 대한 주요 정보를 식별할 수 있습니다.

보안 제어를 구현하려면 다음을 수행합니다.

로그 하위 시스템 장애 시 자동화 컨트롤러를 다른 시스템으로 장애 조치하도록 구성해야 합니다. 자동화 컨트롤러 호스트는 애플리케이션 로그 처리 실패 감지 시 애플리케이션 및 로깅 기능을 처리할 수 있는 다른 자동화 컨트롤러 호스트로 장애 조치할 수 있어야 합니다. 이를 통해 사용자 및 로그 데이터 손실 및 로그 데이터 손실을 최소화하면서 애플리케이션 및 로깅 함수를 지속적으로 수행할 수 있습니다.

보안 제어를 구현하려면 다음을 수행합니다.

보안 관리는 보안 자동화 플랫폼을 유지 관리하는 데 중요한 구성 요소입니다. 다음 보안 관리 방법을 사용하는 것이 좋습니다.

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

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

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

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

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

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

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

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

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

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

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

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