2.3. 초기 구성


시스템의 특정 부분에 대한 액세스 권한을 부여하면 보안 취약점이 노출됩니다. 액세스 보안을 위해 다음 사례를 적용합니다.

  • 시스템 관리 계정에 대한 액세스를 최소화합니다. 사용자 인터페이스(웹 인터페이스)와 자동화 컨트롤러가 실행 중인 운영 체제에 대한 액세스에는 차이점이 있습니다. 시스템 관리자 또는 슈퍼 사용자는 모든 시스템 애플리케이션에 액세스, 편집 및 중단할 수 있습니다. 자동화 컨트롤러에 대한 루트 액세스 권한을 가진 모든 사용자는 이러한 인증 정보를 해독할 수 있으므로 시스템 관리 계정에 대한 액세스를 최소화하는 것이 보안 시스템을 유지하는 데 중요합니다.
  • 로컬 시스템 액세스를 최소화합니다. 자동화 컨트롤러에는 관리 목적을 제외하고 로컬 사용자 액세스 권한이 필요하지 않아야 합니다. 관리자가 아닌 사용자는 자동화 컨트롤러 시스템에 액세스할 수 없어야 합니다.
  • 업무 분리를 시행합니다. 자동화 구성 요소가 서로 다른 수준에서 시스템에 액세스해야 할 수 있습니다. 하나의 키 또는 인증 정보 취약점의 영향을 최소화하도록 각 구성 요소에 대해 서로 다른 키 또는 인증 정보를 사용합니다.
  • 자동화 컨트롤러를 낮은 수준의 자동화 컨트롤러 구성 및 재해 복구에만 가능한 최소 사용자 세트로 제한합니다. 자동화 컨트롤러 컨텍스트에서 모든 자동화 컨트롤러 '시스템 관리자' 또는 '슈퍼유저' 계정은 자동화 컨트롤러에서 인벤토리 또는 자동화 정의를 편집, 변경, 업데이트할 수 있습니다.

2.3.1. 구성을 코드 패러다임으로 사용

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

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

표 2.5. Ansible 콘텐츠 컬렉션

검증된 컬렉션

컬렉션 용도

infra.aap_utilities

설치, 백업 및 복원, 인증서 관리 등 Ansible Automation Platform의 Day 1 및 Day 2 작업을 자동화하는 Ansible 콘텐츠입니다.

infra.aap_configuration

사용자 및 그룹(RBAC), 프로젝트, 작업 템플릿 및 워크플로우, 인증 정보 등을 포함하여 Ansible Automation Platform 구성 요소 생성을 관리하는 역할 컬렉션입니다. 이 컬렉션에는 이전 infra.controller_configuration,infra.ah_configurationinfra.eda_configuration 의 기능이 포함되어 있으며 Ansible Automation Platform 2.5에서 해당 위치에서 사용해야 합니다.

infra.ee_utilities

실행 환경 이미지를 생성 및 관리하거나 이전 Tower Virtualenvs에서 실행 환경으로 마이그레이션하는 역할 컬렉션입니다.

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

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

  • 가져오기 요청 생성.
  • 검사 도구가 있는지 확인합니다.
  • 일반 텍스트 보안이 커밋되지 않도록 합니다.
  • 사전 커밋 후크 및 기타 정책이 준수되었는지 확인합니다.

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

2.3.2. 중앙 집중식 로깅 구성

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

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

  • 데이터는 사용자 지정 처리기에서 또는 가져온 라이브러리를 통해 엔지니어링된 최소 서비스별 조정을 사용하여 HTTP 연결을 통해 JSON 형식으로 전송됩니다. 컨트롤러에 가장 유용한 데이터 유형은 작업 팩트 데이터, 작업 이벤트/작업 실행, 활동 스트림 데이터, 로그 메시지입니다.
  • 플레이북 실행 세부 정보, 작업 결과 및 시스템 이벤트를 포함하여 인프라의 다양한 부분에서 로그를 분석하여 자동화 프로세스에 대한 깊은 통찰력을 제공합니다.
  • 로그에서 실행 시간 및 리소스 사용량을 분석하여 성능 병목 현상을 식별하고 Ansible 플레이북을 최적화합니다.
  • 중앙 집중식 로깅은 감사 목적으로 단일 정보 소스를 제공하여 규정 준수 의무를 충족하는 데 도움이 됩니다.
  • 타사는 Splunk, Logstash, ElasticSearch 또는 Loggly와 같은 중앙 집중식 로그 관리 플랫폼과 통합하여 로그를 수집하고 분석합니다.

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

  • Splunk
  • Loggly
  • Sumologic
  • 탄력적 스택(이전 ELK 스택)

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

절차

  1. 탐색 패널에서 Settings Automation Execution Logging 을 선택합니다.
  2. 로깅 설정 페이지에서 편집 을 클릭합니다.
  3. 다음 옵션을 구성할 수 있습니다.

    • 로깅 수집기: 로그를 보낼 호스트 이름 또는 IP 주소를 입력합니다.
    • 로깅 수집기 포트: 필요한 경우 수집기 포트를 지정합니다.

      참고

      연결 유형이 HTTPS인 경우 포트 번호가 있는 URL로 호스트 이름을 입력할 수 있습니다. 그 후에는 포트를 다시 입력할 필요가 없습니다. 그러나 TCP 및 UDP 연결은 URL이 아닌 호스트 이름 및 포트 번호 조합에 의해 결정됩니다. 따라서 TCP 또는 UDP 연결의 경우 지정된 필드에 포트를 제공합니다. 대신 로깅 수집기 필드에 URL을 입력하면 호스트 이름 부분이 호스트 이름으로 추출됩니다.

    • 로깅 수집기 유형: 목록에서 수집기 서비스를 클릭하여 선택합니다.
    • 로깅 수집기 사용자 이름: 필요한 경우 로깅 수집기의 사용자 이름을 입력합니다.
    • 로깅 수집기 암호/토큰: 필요한 경우 로깅 수집기의 암호를 입력합니다.
    • 로그 수집기 양식에 데이터를 전송하는 로거: 기본적으로 네 가지 데이터 유형이 모두 미리 채워집니다. 각 데이터 유형에 대한 자세한 내용은 필드 옆에 있는 툴팁 Help 아이콘을 클릭합니다. 원하지 않는 데이터 유형을 삭제합니다.
    • 클러스터 전체 고유 식별자: 이 ID를 사용하여 인스턴스를 고유하게 식별합니다.
    • 로깅 수집기 프로토콜: 로깅 수집기와 통신할 연결 유형(프로토콜)을 클릭하여 선택합니다. 후속 옵션은 선택한 프로토콜에 따라 달라집니다.
    • TCP 연결 시간 초과: 연결 시간 초과를 초 단위로 지정합니다. 이 옵션은 HTTPS 및 TCP 로그 수집기 프로토콜에만 적용할 수 있습니다.
    • 로깅 수집기 수준 임계값: 로그 처리기에서 보고할 심각도 수준을 선택합니다.
    • 로그 작업 큐에 저장할 수 있는 최대 메시지 수: rsyslog 작업 큐 가 저장된 메시지 수에서 증가할 수 있는 크기를 정의합니다. 이는 메모리 사용에 영향을 미칠 수 있습니다. 큐가 이 번호의 75%에 도달하면 큐에 디스크 쓰기를 시작합니다( rsyslogqueue.highWatermark ). 90%에 도달하면 NOTICE,INFO, DEBUG 메시지가 삭제되기 시작합니다( queue.discard Severity=5가 있는 queue.discardmark).
    • rsyslogd 작업 대기열(GB)의 최대 디스크 지속성: rsyslog 작업이 들어오는 메시지를 처리하는 데 시간이 걸리는 경우 저장할 데이터 양(GB 단위)입니다(기본값: 1). 작업의 rsyslogd queue.maxdiskspace 설정(예: omhttp)과 동일합니다. LOG_AGGREGATOR_MAX_DISK_USAGE_PATH 에 지정된 디렉터리에 파일을 저장합니다.
    • rsyslogd 디스크 지속성을 위한 파일 시스템 위치: 외부 로그 수집기가 중단된 후 다시 시도해야 하는 로그를 유지할 위치(기본값: /var/lib/awx). rsyslogd queue.spoolDirectory 설정과 동일합니다.
    • API 4XX 오류의 로그 형식: 특정 오류 메시지 구성. 자세한 내용은 API 4XX 오류 구성 설정을 참조하십시오.
    • 시스템 추적 사실을 개별적으로 기록: 설정할지 또는 기본적으로 해제할지 여부와 같은 추가 정보를 보려면 툴팁 Help 아이콘을 클릭합니다.
  4. 선택한 로깅 집계에 대한 입력을 검토합니다.

    • 외부 로깅 활성화: 외부 로그 수집기로 로그를 보내려면 이 확인란을 선택합니다.
    • HTTPS 인증서 확인 활성화/비활성화: HTTPS 로그 프로토콜에 대해 기본적으로 인증서 확인이 활성화됩니다. 로그 처리기에서 연결을 설정하기 전에 외부 로그 수집기가 전송한 HTTPS 인증서를 확인하려면 이 확인란을 선택합니다.
    • rsyslogd 디버깅 활성화: rsyslogd 에 대한 상세 정보 표시 디버깅을 활성화하려면 이 확인란을 선택합니다. 외부 로그 집계에 대한 연결 문제를 디버깅하는 데 유용합니다.
  5. 저장 또는 취소 를 클릭하여 변경 사항을 취소합니다.

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

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

절차

  1. 게이트웨이 설정 파일을 편집합니다.

    1. Ansible Automation Platform2.5 Containerized에서 파일은 ~/aap/gateway/etc/settings.py (플랫폼 게이트웨이 컨테이너를 실행하는 사용자)입니다.
    2. Ansible Automation Platform2.5 RPM 기반에서 파일은 /etc/ansible-automation-platform/gateway/settings.py 입니다.

      Copy to Clipboard Toggle word wrap
       (...)
        CACHES['fallback']['LOCATION'] = '/var/cache/ansible-automation-platform/gateway'
      
        LOGGING['loggers']['aap']['level'] = 'INFO'
        LOGGING['loggers']['ansible_base']['level'] = 'INFO'
        LOGGING['loggers']['django_auth_ldap']['level'] = 'DEBUG'      ######      add this line
      
        (...)
  2. 플랫폼 게이트웨이 서비스 또는 컨테이너를 다시 시작합니다.

    1. Ansible Automation Platform2.5 Containerized에서 플랫폼 게이트웨이 컨테이너를 다시 시작하도록 플랫폼 게이트웨이 서비스를 다시 시작합니다.

      참고

      다음과 같이 '--user' 플래그를 사용하여 systemctl 을 실행해야 합니다.

      + $ systemctl --user restart automation-gateway

    2. Ansible Automation Platform2.5 RPM 기반에서 automation-gateway-service 명령을 사용합니다.

      # automation-gateway-service restart

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

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

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

절차

  1. 자동화 컨트롤러에 관리자로 로그인합니다.
  2. 탐색 패널에서 Settings Automation Execution Logging 을 선택합니다.
  3. 로깅 설정 페이지에서 편집 을 클릭합니다.
  4. 다음 필드를 설정합니다.

    • 로깅 수집기Not configured 로 설정합니다. 이는 기본값입니다.
    • 외부 로깅 활성화를 On 으로 설정합니다.
    • 로깅 수집기 수준 임계값 을 DEBUG로 설정합니다.
    • TCP 연결 시간 초과 를 5(기본값) 또는 조직의 시간 초과로 설정합니다.
    • HTTPS 인증서 확인 활성화/비활성화On 으로 설정합니다.
  5. 저장을 클릭합니다.

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

  1. 로그 레코드 스토리지 용량이 부족하여 오류가 발생한 경우 애플리케이션에서 로그 레코드를 계속 생성해야 합니다(필요한 경우 로그 서비스를 자동으로 다시 시작) 첫 번째 시작 방식으로 가장 오래된 로그 레코드를 덮어써야 합니다.
  2. 로그 레코드가 중앙 집중식 컬렉션 서버로 전송되고 이 서버와의 통신이 유실되거나 서버가 실패하는 경우 통신이 복원되거나 로그 레코드가 수동으로 검색될 때까지 애플리케이션은 로컬로 로그 레코드를 큐해야 합니다. 중앙 집중식 컬렉션 서버에 대한 연결을 복원하는 경우 로컬 로그 데이터를 컬렉션 서버와 동기화하려면 작업을 수행해야 합니다.

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

    1. 웹 브라우저를 열고 로깅 API, /api/v2/settings/logging/로 이동합니다.

      자동화 컨트롤러 관리자로 인증되었는지 확인합니다.

    2. Content 섹션에서 다음 값을 수정합니다.

      • 로그 버퍼링에 대한 LOG_AGGREGATOR_ACTION_MAX_DISK_USAGE_GB = 조직 정의 요구 사항.
      • LOG_AGGREGATOR_MAX_DISK_USAGE_PATH = /var/lib/awx` ..Click PUT.

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

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

절차

  1. 탐색 패널에서 Settings Automation Execution System 을 선택합니다. 시스템 설정 페이지가 표시됩니다.
  2. 편집을 클릭합니다.
  3. 다음을 설정합니다.

    • 활동 스트림 활성화 = On
    • 인벤토리 동기화를 위해 활동 스트림 활성화 = On
    • 조직 관리자는 사용자와 팀을 관리할 수 있습니다 = On
    • 조직 관리자가 모든 사용자를 볼 수 있음 = On
  4. 저장을 클릭합니다.

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

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

절차

  1. 각 자동화 컨트롤러 호스트의 시스템 관리자로 자동화 컨트롤러 NGINX 로그 디렉터리의 권한 및 소유자를 설정합니다.

    • `chmod 770 /var/log/nginx
    • chown nginx:root /var/log/nginx
  2. 자동화 컨트롤러 로그 디렉터리의 권한 및 소유자를 설정합니다.

    • chmod 770 /var/log/tower
    • chown awx:awx /var/log/tower
  3. 자동화 컨트롤러 감독자 로그 디렉터리의 권한 및 소유자를 설정합니다.

    • chmod 770 /var/log/supervisor/
    • chown root:root /var/log/supervisor/

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

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

  • 자동화 컨트롤러가 HA 구성에 없는 경우 관리자는 자동화 컨트롤러를 다시 설치해야 합니다.

2.3.3. 외부 인증 정보 자격 증명 모음 고려 사항

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

  • 시스템에 액세스할 수 있는 권한이 없는 사용자가 없는지 확인하고 액세스가 필요한 사용자에게만 부여되어야 합니다. 자동화 컨트롤러는 암호 및 API 토큰과 같은 중요한 정보를 암호화하지만 암호 해독에 키를 저장합니다. 권한이 부여된 사용자는 잠재적으로 모든 것에 액세스할 수 있습니다.
  • 외부 시스템을 사용하여 시크릿을 관리합니다. 자격 증명을 업데이트해야 하는 경우 외부 시스템은 내부 시스템보다 덜 복잡한 업데이트된 자격 증명을 검색할 수 있습니다. 시크릿을 관리하기 위한 외부 시스템에는 CyberArk, HashiCorp Vault, Microsoft Azure Key Management 등이 있습니다. 자세한 내용은 자동화 실행 사용의 시크릿 관리 시스템 섹션을 참조하십시오.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat, Inc.