Invoke tagging discipline across organization in AWS - 1

조직이 다수의 AWS 계정을 운용하기 전에 성장하면 조직 내의 자원을 망라적으로 관리할 의향이 있다.
많은 자원 유형이 지원됩니다표식. 사용자별 관리 정책을 반영하는 데 사용됩니다.그러나 이 점을 아무리 관철하고 싶어도 스태프들의 자조적인 노력, 성선성만을 기대하는 것만으로는 부족하다는 것은 상상하기 쉽다.아무리'철저히'등 쓴소리를 해도 결국은 귀찮아지고 스태프 이동 등 형해화되는 게 아저씨 아닌가.더군다나 계좌번호가 여러 개야.확장 가능한 조직 성장의 측면에서 볼 때, 우리도 더욱 스마트한 해결 방안이 필요하다.

AWS 무슨 소리야?

그래서 AWS의 공식 문서 등으로 눈을 돌리면 이런 말이 나온다.
(pdf 참고) https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf
Abstract
Without the use of tags, it can become difficult to manage your resources effectively as your utilization of AWS services grows. However, it is not always evident how to determine what tags to use and for which types of resources. The goal of this whitepaper is to help you develop a tagging strategy that enables you to manage your AWS resources more effectively.
태그를 사용하지 않으면 AWS 서비스의 사용이 계속 확대되는 과정에서 자원을 효과적으로 관리하는 것이 어려워질 수 있습니다.그러나 어떤 종류의 자원에 어떤 표시를 사용해야 하는지, 그리고 그것을 어떻게 확정해야 하는지 잘 알지 못합니다.이 백서는 AWS 리소스를 보다 효과적으로 관리할 수 있도록 태그 정책을 수립하는 데 도움을 줍니다.
Beyond Good Intentions
All of these tools and recommendations create a strong foundation, and you might start to use tags with only the very best of intentions. However, as Jeff Bezos, often reminds us, “Good intentions don’t work, but mechanisms do.” Standardizing on names, values, capitalization, and punctuation is a great idea, but challenging to put in to practice. When tags are used to control access to resources or to divvy up bills, small errors can create big problems!
선의를 초월하다
이 모든 도구와 건의는 튼튼한 기초를 닦았고, 아마도 아주 좋은 의도에서 라벨을 사용하기 시작했을 것이다.그러나 제프 베조스가 자주 말한 것처럼 "선의는 작용하지 않지만 메커니즘은 효과가 있다."명칭, 값, 대문자, 문장부호를 표준화하는 것은 좋은 생각이지만 실제로 실행하기는 매우 어렵다.만약 표시가 자원에 대한 접근을 제어하거나 영수증을 분할하는 데 사용된다면, 작은 오류는 큰 문제를 초래할 수 있다.
일본어 번역은 필자가 기계적으로 번역한 것으로 Good intentions는 선의로 번역되었다.선의에 의존하지 않는 메커니즘이 바로 Tag Policies입니다.

조직 가져오기 방법

기획 입안 단계에서 크로스 조직 그룹으로 논의한 결과 얻은 협의는 다음과 같다.

태그 정책은 여전히 유효하다고 여겨진다.들어가자

그러나 현재 안전 관리 전담팀이 부합되지 않는 정보를 검출할 수 있다면

갑자기 문답이 필요 없이 비표준 조작을 금지하는 것은 좀 지나치다

금지 등 강력한 조치를 선택항목으로 배제하지 않지만 일단 검측만으로 숙련된 뒤 상황에 따라 연구

보안 Hub를 위해 이전에 구성된 알림 시스템에서 보듯이 이상적인 것은 비상용 정보를 전용 Slack channel에 집중하는 것이다

부합되지 않는 사항을 통지한 경우 관할 대상 자원의 개발진에게 매번 제시하는 등 개별적으로 대응하는 운용

이전 보도에서 소개한 Security Hub의 CRITICALfindings를 slack에 집중시키는 구조는 현재 잘 활용되고 있다고 생각합니다.findings가 오면 이 팀에 remediation을 포함한다고 암시하고 해결합니다. 이런 주기는 대체적으로 확립되어 있습니다. (최초 알림이 대량으로 와서 고생했습니다)
따라서 이번에findings를 표기 규칙에 부합되지 않는 사항으로 바꾸어 같은 해결 절차를 확립할 수 있을지 궁금합니다.이렇게 되면 통지부터 대응은 여전히 사람의 개입이 필요하지만 비상용 자원을 구체적으로 설명하고 해결을 추진하는 구조가 있다.최근에 목표를 여기까지로 정하고 자동화, 엄격화를 미래의 과제로 삼았다

배치

그럼 실제로 Tag Policies에 가입합시다.이 프로세스을 따라 가다.하지만 이 기사는 기본적으로 CLI에서 진행됩니다.
도입 프로그램은 단지 하나의 예에 대한 소개일 뿐 정부 정보와 동등한 품질을 보장할 수 없다.모범 사례 및 권장 워크플로우 등 건강한 도입 체험에 주의하세요.검증을 위한 원본 버전에 익숙해지면 안심할 수 있습니다
주 계정에서 주문 처리

Creating Tag Policies

enable-policy-type

aws organizations list-roots --query 'Roots[*].Id' --output text |
  xargs aws organizations enable-policy-type \
    --policy-type TAG_POLICY                 \
    --root-id

※ 다음은 마스터 계정 측에서 구성원 계정 그룹에 액세스하는 데 필요한 설정

aws organizations enable-aws-service-access --service-principal tagpolicies.tag.amazonaws.com

다음 명령 정의 유효 json 파일

aws organizations create-policy                                                      \
  --name "general"                                                                   \
  --description "Tag policy generally supposed to be followed in the organization"   \
  --content file://"organizations/general-tag-policy.json"                           \
  --type TAG_POLICY

다음은 루트 바로 아래에 있는 OU 이름$ou에 $policy_id을 추가합니다.각 유효한 값 정의

aws organizations list-roots --query 'Roots[*].Id' --output text | xargs aws organizations list-organizational-units-for-parent --query 'OrganizationalUnits[?Name==`'$ou'`].Id' --output text --parent-id | xargs aws organizations attach-policy --policy-id $policy_id --target-id

Checking Policy Compliance

% aws resourcegroupstaggingapi get-compliance-summary
{
    "SummaryList": [
        {
            "LastUpdated": "2020-12-02T18:50:42Z",
            "NonCompliantResources": 0
        }
    ]
}

※ 다음 오류 메시지가 발생하면 대책으로 상기enable-aws-service-access를 수행합니다.
An error occurred (ConstraintViolationException) when calling the GetComplianceSummary operation: Access to tag policies is not enabled. To enable it, run the AWS Organizations EnableAWSServiceAccess action and specify tagpolicies.tag.amazonaws.com for the service principal.

추가 구성원 계정 확인 방법 (optional)

이전 섹션에서 지정한 OU 아래에 배치된 구성원 계정에서 단일 정보 찾아보기
아래PolicyContent는 Master Account에서 정의한 정책 소스여야 합니다.
기본 계정이 아닌 구성원 계정에서 실행
정책 영향 여부 확인

% aws organizations describe-effective-policy \
    --policy-type TAG_POLICY
{
    "EffectivePolicy": {
        "PolicyContent": "JSON_STRING_DEFINED_BY_YOURSELF_ON_MASTER_ACCOUNT",
        "TargetId": "111111111111",
        "PolicyType": "TAG_POLICY"
    }
}

규정 준수

% aws resourcegroupstaggingapi get-resources \
    --include-compliance-details \
    --exclude-compliant-resources
{
    "ResourceTagMappingList": []
}

EC2 Instance 등에서 적절한 태그를 정의하고 결과를 비교하십시오.서로 용납되지 않는 자원이 있으면 이 정보를 되돌려줍니다.위의 예시에서 결과는 서로 용납되지 않는 자원이 없다.

다음 도전

그렇다면 실제로 해보면 평가 결과의 내용을 자세히 보면'원래 정책에서 정의한 라벨 자체가 부여되지 않은 자원은 비준거로 간주되지 않는다'는 점에 주목할 수 있다.
근데 이거 그런 스타일 같은데.
그러면 지정된 레이블에 지정된 리소스 유형(예: EC2 Instance)이 부여되어야 하는 규칙이 지정되면 어떻게 구현해야 합니까?
Tag policies 콘솔을 보세요. 이런 일이 적혀 있어요.
Did you know?
You can use service control policies (SCPs) with tag policies. You can use SCPs to require tags when creating new resources, and use tag policies to ensure that changes to the tags are always compliant. Learn more
이에 따라 Tag policies와 병행하여 SCP는 태그 자체를 요구할 수 있을 것 같습니다.그러나 이렇게 하면 지정한 라벨을 추가하지 않으면 자원을 만드는 것을 금지하는 것은 매우 강한 제한이다.
그러나 우리 조직에서 최근 실현하고자 하는 것은 비부합적인 검측뿐이다.앞으로 금지의 엄격화가 뒤따를 것을 감안하더라도 지금은 당장은 아니다.
이 작업을 엄격하게 수행하려면 기존 CloudFormation 템플릿을 업데이트하는 것을 고려해야 할 수도 있습니다. 또한 모든 개발진이 이 템플릿이 누락되지 않도록 해야 합니다.ec2 실례에서 고려하면 실행 중인 Auto Scaling Group 등에 영향을 미칠 수 있다.그럼에도 불구하고 금지된 규칙을 갑자기 강제적으로 적용하면 문제다. ※같은 이유로 enforced_for 채택이 이번에도 미뤄졌습니다.
그럼 어떻게 하면 좋을까요?SCP 대신 AWS Config의 관리 규칙required-tags을 사용하고 싶습니다.
다음