14. 보안 모범 사례¶

14.3.1. 관리 계정 최소화¶

시스템 관리 계정에 대한 액세스를 최소화하는 것이 보안 시스템 유지에 중요합니다. 시스템 관리자/root 사용자는 모든 시스템 애플리케이션에 액세스하고 편집 및 방해할 수 있습니다. root 액세스 권한을 가진 사용자/계정 수를 가능한 한 작은 그룹으로 유지합니다. `root`에 `sudo`를 제공하거나 신뢰할 수 없는 사용자에게 `awx`(컨트롤러 사용자)를 제공하지 마십시오. `sudo`와 같은 메커니즘을 통해 관리 액세스를 제한할 때 특정 명령 세트로 제한하면 여전히 광범위한 액세스 권한이 부여될 수 있습니다. 쉘 또는 임의 쉘 명령을 실행할 수 있는 명령이나 시스템의 파일을 변경할 수 있는 명령은 근본적으로 전체 root 액세스와 동일합니다.

컨트롤러 컨텍스트에서 컨트롤러 〈시스템 관리자〉 또는 〈슈퍼유저〉 계정은 컨트롤러의 모든 인벤토리 또는 자동화 정의를 편집, 변경, 업데이트할 수 있습니다. 하위 수준의 컨트롤러 구성과 재해 복구에 대해서만 가능한 최소 사용자 세트로 제한합니다.

14.3.2. 로컬 시스템 액세스 최소화¶

모범 사례와 함께 사용할 경우 |at|에서는 관리 목적을 제외하고 로컬 사용자 액세스 권한이 필요하지 않습니다. 관리자가 아닌 사용자는 컨트롤러 시스템에 액세스할 수 없어야 합니다.

14.3.3. 사용자의 인증 정보에 대한 액세스 제거¶

자동화 인증 정보가 컨트롤러에만 저장된 경우 인증 정보를 추가로 보호할 수 있습니다. 특정 주소의 연결에 대한 인증 정보만 허용하도록 OpenSSH와 같은 서비스를 구성할 수 있습니다. 자동화에 사용되는 인증 정보는 시스템 관리자가 재해 복구 또는 기타 애드혹 관리에 사용하는 인증 정보와 다를 수 있으므로 감사가 더 쉬워집니다.

14.3.4. 업무 분리 적용¶

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

14.4.1. 감사 및 로깅 기능¶

관리 액세스의 경우 작업을 감사하고 감시하는 것이 중요합니다. 시스템 전체의 경우 기본 제공 감사 지원(https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/chap-system_auditing.html)과 기본 제공 로깅 지원을 통해 이 작업을 수행할 수 있습니다.

|at|의 경우 컨트롤러 내의 모든 변경 사항을 로깅하는 기본 제공 활동 스트림 지원과 자동화 로그를 통해 작업이 수행됩니다.

모범 사례에 따라 로컬 시스템에서 검토하는 대신 중앙에서 로깅을 수집하고 감사하는 것이 좋습니다. 환경의 표준인 IDS 및/또는 로깅/감사(Splunk)를 사용하도록 |at|를 구성하는 것이 좋습니다. |at|에는 Elastic Stack, Splunk, Sumologic, Loggly 등에 대한 기본 제공 로깅 통합이 포함되어 있습니다. 자세한 내용은 :ref:`ag_logging`을 참조하십시오.

14.4.2. 기존 보안 기능¶

SELinux를 비활성화하지 말고, 컨트롤러의 기존 멀티 테넌트 포함을 비활성화하지 마십시오. 컨트롤러의 RBAC(역할 기반 액세스 제어)를 사용하여 자동화를 실행하는 데 필요한 최소 수준의 권한을 위임합니다. 컨트롤러에서 Teams를 사용하여 사용자 개인이 아닌 사용자 그룹에 권한을 할당합니다. |atu|에서 :ref:`rbac-ug`를 참조하십시오.

14.4.3. 외부 계정 저장소¶

컨트롤러에서만 전체 사용자 세트를 유지하는 것은 대규모 조직에서 시간이 많이 걸리는 작업이며 오류가 발생할 수 있습니다. |At|에서는 LDAP, SAML 2.0, 특정 :ref:`OAuth providers <ag_social_auth>`를 통해 외부 계정 소스에 연결할 수 있도록 지원합니다. 이 기능을 사용하면 권한 작업 시 오류 소스가 제거됩니다.

14.4.4. Django 암호 정책¶

컨트롤러 관리자는 Django를 활용하여 생성 시 AUTH_PASSWORD_VALIDATORS``를 통해 컨트롤러 사용자 암호를 검증하기 위한 암호 정책을 설정할 수 있습니다. 컨트롤러 인스턴스의 ``/etc/tower/conf.d``에 있는 ``custom.py 파일에서 다음 코드 블록 예제를 추가합니다.

AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
        'OPTIONS': {
            'min_length': 9,
        }
    },
    {
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]

자세한 내용은 위에 게시된 예제 외에 `Password management in Django <https://docs.djangoproject.com/en/3.2/topics/auth/passwords/#module-django.contrib.auth.password_validation>`_를 참조하십시오.

변경 사항을 적용하려면 컨트롤러 인스턴스를 재시작해야 합니다. 자세한 내용은 :ref:`ag_restart_tower`를 참조하십시오.