허용 목록과 거부 목록

탄소 기반 물 주머니의 타고난 특징 중 하나는 주변 환경을 정리할 필요가 있다는 것입니다. 우리가 정말로 무언가를 이해하려면 먼저 그것이 어떻게 구성되어 있는지 살펴볼 필요가 있습니다. 이제 사람들은 조직을 정말 사랑하면 '문화'라고 부르고, 조직을 싫어하면 다른 사람의 탓으로 돌립니다.

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

거부할지 허용할지, 이것이 문제입니다.

거부 목록은 정확히 차단해야 한다고 명시한 데이터를 제외한 모든 데이터의 흐름을 허용하는 위협 중심 모델의 일부입니다. 여기서 문제는 제로데이 공격은 정의상 알려지지 않았기 때문에 기본적으로 허용되며 오탐과 마찬가지로 투명하다는 것입니다. 

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

허용 목록은 모든 것을 거부하고 명시적으로 허용하는 것만 허용하는 신뢰 중심 모델을 따르며, 오늘날의 데이터 센터에서는 더 나은 선택입니다. 현실을 직시하자, 데이터 센터에서 연결하고 싶은 항목의 목록은 연결하고 싶지 않은 항목보다 훨씬 적죠? 이렇게 하면 오탐을 제거하지는 못하더라도 즉시 오탐을 줄일 수 있습니다.

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

항상 회색 영역이 존재합니다.

물론 회색 영역이 있습니다. 다른 IT 사례와 마찬가지로, "대부분의 경우, 대부분의 시간에 세상은 끊임없이 변화한다"는 카이퍼의 공리를 항상 염두에 두어야 합니다. 또는 "상황에 따라 다릅니다."라고 부르기도 합니다. 

접근 제어 목록은 기술적으로 거부 또는 허용 목록으로 사용할 수 있기 때문에 이 방정식에서 "상황에 따라 달라진다"고 할 수 있습니다. (방금 마이클 잭슨 노래를 따라 부르기 시작했다면, 당신은 대단한 사람입니다!) 네트워킹 101 수강생이라면 누구나 알 수 있듯이 ACL은 마지막에 암시적으로 "거부"라는 문구가 있어 허용 목록이 됩니다. 그러나 일반적인 모범 사례로 ACL에 DENY 문을 넣고 마지막에 "허용하지 않음"을 추가하여 거부 목록으로 바꿉니다.

이제 어떻게 할까요?

보안은 훌륭한 레드벨벳 케이크와 같아서 겹겹이 쌓으면 모든 차이를 만들어냅니다. 하나의 솔루션이 모든 것을 해결할 수는 없습니다. 사실 거부자는 이론상으로는 훨씬 덜 힘든 일입니다. 문제는 위협이 증가함에 따라 거부자의 효율성이 점점 떨어지고 있다는 점입니다. 오류가 발생하기 쉽고 장기적으로 더 많은 유지 관리가 필요합니다. 

거부자는 네트워크의 경계에서 남북 데이터 흐름의 경계에 위치하며, 경계가 더 정적이고 거친 필터 역할을 합니다. 하지만 데이터 센터 내부는 대부분의 트래픽이 흐르는 곳입니다. 여기에는 IP 주소 변경, 애플리케이션의 가동 및 중단 등 사방으로 이동하는 워크로드를 보호하기 위해 세밀한 제어가 필요합니다. 허용 목록은 횡방향 데이터 흐름을 위한 완벽한 솔루션입니다. 기본적으로 그들은 아무것도 신뢰하지 않습니다. 

아버지는 "망치만 있으면 모든 것이 못이다"라고 말씀하시곤 하셨죠. 오늘날의 대규모 확장성과 유연성을 갖춘 데이터 센터에서는 이제 망치를 내려놓고 정밀한 도구를 사용해야 할 때입니다.