허용 목록과 거부 목록

탄소 기반 물주머니의 고유한 특징 중 하나는 주변 환경을 정리해야 한다는 것입니다.정말로 이해하고 싶은 것이 있다면 먼저 그것이 어떻게 정리되어 있는지 살펴봐야 합니다.이제 사람들은 자신의 조직을 정말 사랑할 때 그것을 “문화”라고 부르고, 싫어할 때는 다른 사람들 탓으로 돌립니다.

컴퓨터 과학에서는 모든 곳에서 데이터를 정리합니다.예를 들어 보안은 관계와 관련된 조직이라는 개념과 우리가 관계를 허용할지 거부하는지를 기반으로 합니다.조직의 한쪽에는 거부 리스트가 있고 다른 한쪽에는 허용 리스트가 있습니다.기억하세요. 저희가 하려는 것은 다른 주체로부터의 트래픽을 허용하거나 거부하는 것뿐입니다.

목록을 거부하거나 허용 목록에 추가하는 것이 문제입니다.

거부 목록은 차단해야 한다고 말한 내용을 제외하고 모든 데이터가 흐르도록 허용하는 위협 중심 모델의 일부입니다.여기서 문제는 그 이후부터라는 것입니다. 제로데이 공격 정의상 알 수 없지만 기본적으로 허용되며 오탐과 마찬가지로 투명합니다.

또한 거부 목록은 리소스를 많이 사용하는 경향이 있습니다.전체 파일을 읽은 다음 모놀리식 방식으로 허용 또는 거부를 결정하려면 많은 CPU 사이클이 필요합니다.또한 최신 상태로 유지하려면 정기적인 수동 업데이트나 동적 서비스가 필요합니다.

허용 목록은 모든 것을 거부하고 명시적으로 허용한 부분만 허용하는 신뢰 중심 모델을 따릅니다. 이는 오늘날의 데이터 센터에서 더 나은 선택입니다.솔직히 말씀드리자면, 여러분이 해야 할 일의 목록은 다음과 같습니다.해야 할 것데이터 센터에 연결하고 싶은 것이 당신보다 훨씬 작습니다.하지 마세요연결하고 싶어요, 그렇죠?이렇게 하면 오탐이 없어지지는 않더라도 즉시 줄어듭니다.

허용 목록은 시스템 리소스가 적기 때문에 서버에 적합합니다.흐름의 메타데이터를 읽고 파일 이름을 기준으로 인덱싱한 다음 로컬 소스에서 허용하거나 거부합니다.간단하고 빠릅니다.하지만 허용 목록의 아킬레스건은 이를 관리하는 것입니다.기본적으로 가능한 모든 워크로드를 오가는 가능한 모든 트래픽 흐름을 가능한 모든 조합으로 관리하고 있다고 가정해 보세요.허용 목록도 물론 좋지만, 중앙 집중식 컨트롤러가 필요하신가요?

항상 회색 영역이 있습니다.

물론 회색 영역이 있습니다.모든 IT 사례와 마찬가지로 카이퍼스의 원칙에 항상 귀를 기울여야 합니다. “세상은 대부분의 면에서, 기껏해야 끊임없이 변화합니다.”우리가 말하는 것처럼 “상황에 따라 다릅니다.”

액세스 제어 목록은 기술적으로 거부 또는 허용 목록으로 사용될 수 있기 때문에 이 방정식에서 “상황에 따라 달라집니다”.(마이클 잭슨 곡을 이제 막 부르기 시작했다면 정말 멋지죠!)Networking 101 학생이라면 누구나 알 수 있듯이 ACL 말미에 “Deny any any”라는 문구가 내포되어 있어 허용 목록에 속합니다.하지만 일반적인 모범 사례로 ACL에 DENY 문을 넣고 끝에 “any any allow”를 붙이는 방식으로 이를 거부 목록으로 만듭니다.

자, 이제 어떡하죠?

보안은 마치 멋진 레드 벨벳 케이크와 같습니다. 여러 겹으로 겹쳐 입으면 모든 것이 달라집니다.단 하나의 해결책으로는 모든 것이 끝날 수 없습니다.솔직히, 치과 의사들은 이론상으로는 일이 훨씬 적어요.문제는 위협이 증가할수록 거부 리스트의 효율성이 점점 떨어진다는 것입니다.오류가 발생하기 쉬우며 장기적으로 볼 때 더 많은 유지 관리가 필요합니다.

북-남 데이터 흐름의 경우 거부 리스트는 네트워크 경계에서 자리를 잡습니다. 여기서 경계는 더 정적이고 거친 필터 역할을 합니다.하지만 대부분의 트래픽이 흐르는 곳은 데이터 센터 내부입니다.여기저기로 이동하는 워크로드, IP 주소 변경, 애플리케이션 가동 및 축소 등을 방지하려면 세분화된 제어가 필요합니다. 허용 목록은 East-West 데이터 흐름을 위한 완벽한 솔루션입니다.기본적으로 이들은 아무것도 신뢰하지 않습니다.

아버지는 “망치만 있으면 모든 것이 못이야.” 라고 말씀하시곤 하셨어요.대규모로 확장 가능하고 유연한 오늘날의 데이터 센터에서는 이제 망치를 떨쳐버리고 정밀 도구를 챙겨야 할 때입니다.