정책 리스크를 파악하십시오. 정책에 대한 질문을 일상 언어로 하십시오. 데모 신청하기 →
Published:
임시 접근 권한이 영구적인 방화벽 정책이 되어서는 안 됩니다
임시 방화벽 접근 권한이 본래 목적을 다한 뒤에도 그대로 남아 있는 이유와, 소유자 지정, 신청 사유, 만료일, 정기 검토를 통해 기한이 정해진 룰을 관리하는 방법을 알아보십시오.
by FireMon
임시 접근은 어느새 영구적인 상태로 남는 경향이 있습니다.
프로젝트, 협력업체, 마이그레이션 또는 긴급 요청을 위해 룰이 생성됩니다. 생성 시점에는 모두가 그 이유를 알고 있습니다. 그러나 몇 달이 지나면 그 맥락을 찾기는 훨씬 어려워집니다.
누가 요청했는가? 누가 승인했는가? 어떤 비즈니스 요구를 뒷받침했는가? 그 접근은 여전히 필요한가?
이러한 정보가 없으면 기술적으로 유효한 방화벽 룰조차 평가하기 어려워집니다.
효과적인 정책 관리를 위해서는 룰이 무엇을 허용하는지 아는 것만으로는 충분하지 않습니다. 팀은 또한 해당 룰이 왜 존재하며 누가 그 책임을 지고 있는지 알아야 합니다.
의사결정이 생생할 때 맥락을 기록하십시오
위 영상에서 FireMon의 Global Field Engineering 담당 Senior Director인 Rob Rodriguez가 방화벽 룰에 담긴 비즈니스 맥락을 Security Manager에서 직접 문서화하는 방법을 보여줍니다.
이러한 맥락에는 다음과 같은 정보가 포함될 수 있습니다:
- 비즈니스 정당성
- 사업부
- 룰 소유자
- 요청자 및 승인자
- 변경 관리 정보
- 다음 검토 일자
- 만료 일자
Rob이 보여주는 예시에는 “Temp Access”라는 라벨이 붙어 있으며, 이는 정책 관리에서 흔히 나타나는 문제를 잘 보여줍니다.
임시 접근은 필요할 수 있습니다. 위험은 해당 접근을 언제 종료해야 하는지 판단할 명확한 메커니즘이 없을 때 발생합니다.
만료 일자나 예정된 검토는 체크포인트를 만듭니다. 몇 달 후 누군가가 최초 요청을 기억해 주기를 기대하는 대신, 정책 자체가 그 결정을 다시 검토하는 데 필요한 정보를 담게 됩니다.
나중에 룰을 평가하기 쉽게 만드십시오
기술적 구성은 방화벽 룰이 무엇을 하는지 알려줍니다.
문서화는 그 룰이 왜 존재하는지 알려줍니다.
환경이 커지고 팀 구성이 바뀔수록 이 차이는 점점 더 중요해집니다.
룰이 생성된 지 6개월 후에 이를 검토하는 엔지니어는 최초 요청에 관여하지 않았을 수 있습니다. 애플리케이션 담당자가 다른 역할로 이동했을 수도 있고, 프로젝트가 이미 종료되었을 수도 있으며, 해당 협력업체와의 관계가 더 이상 유지되지 않을 수도 있습니다.
소유자 정보와 비즈니스 정당성이 없으면, 팀은 해당 접근이 여전히 적절한지 판단하기 전에 룰의 이력을 처음부터 재구성해야 합니다.
이러한 정보를 사전에 문서화하면 향후 검토가 훨씬 수월해집니다.
“이 룰이 무엇을 위한 것인지 아는 사람 있습니까?”라고 묻는 대신, 실무자는 문서화된 목적과 소유자, 검토 일정에서 출발할 수 있습니다.
임시 접근에 종료 일자를 부여하십시오
임시 룰은 본래 목적이 특정 이벤트나 기간에 연결되어 있는 경우가 많기 때문에 각별한 주의가 필요합니다.
유지보수 작업 시간, 마이그레이션, 테스트 기간, 서드파티 업무, 단기 비즈니스 요구 등이 여기에 해당할 수 있습니다.
만료 일자나 검토 절차 없이 룰을 생성하면, 최초의 필요가 사라진 뒤에도 해당 접근이 오랫동안 남아 있을 수 있습니다.
더 나은 프로세스는 기술적인 룰을 그 비즈니스 라이프사이클과 연결합니다.
접근에 소유자, 정당성, 검토 일자가 지정되어 있으면 팀은 그 접근을 계속 유지해야 하는지 판단할 명확한 근거를 갖게 됩니다.
이는 지정된 날짜가 되면 모든 임시 룰을 자동으로 삭제한다는 의미가 아닙니다. 접근이 기본값으로 무기한 유지되도록 방치하는 대신, 의도적인 검토 시점을 마련한다는 뜻입니다.
방화벽 룰을 거버넌스 대상 의사결정으로 전환하십시오
룰을 단순한 구성 객체가 아니라 비즈니스 의사결정으로 다룰 때 방화벽 정책 관리는 훨씬 쉬워집니다.
FireMon은 팀이 기술적인 정책을 해당 접근을 지속적으로 관리하는 데 필요한 소유자, 정당성, 검토 정보와 연결할 수 있도록 지원합니다.
그 결과 접근이 존재하는 이유에 대한 더 명확한 기록과, 그 접근이 여전히 필요한지 판단할 보다 실용적인 방법을 확보하게 됩니다.
중요한 것은 룰이 오늘 작동하는지만이 아닙니다. 내일도 조직이 그 접근을 이해하고, 책임지며, 필요로 할 것인지가 핵심입니다.
비즈니스 맥락을 방화벽 정책 관리에 반영하십시오. FireMon Security Manager 가 복잡한 환경 전반에서 팀이 보안 정책을 이해하고 문서화하며 통제할 수 있도록 어떻게 지원하는지 알아보십시오.
자주 묻는 질문
임시 방화벽 접근은 소유자, 비즈니스 정당성, 만료 일자 또는 검토 일자 없이 룰이 생성될 때 영구적인 상태로 남습니다. 룰을 생성하는 시점에는 모두가 그 존재 이유를 알고 있습니다. 그러나 몇 달이 지나면 요청자는 다른 업무로 이동했을 수 있고 프로젝트도 종료되었을 수 있습니다. 해당 접근이 여전히 필요한지 아무도 답할 수 없다면, 그 룰은 기본값으로 그대로 유지됩니다.
임시 접근이 방치되면 방화벽 룰은 기술적으로는 유효하지만 평가하기 어려운 상태가 됩니다. 팀은 그 룰이 무엇을 허용하는지는 확인할 수 있어도 왜 존재하는지, 누가 책임을 지는지는 알 수 없기 때문에 최초의 필요가 사라진 뒤에도 접근이 오랫동안 남아 있을 수 있습니다. 결국 검토자는 그 접근이 여전히 적절한지 판단하기 전에 룰의 이력을 재구성해야 합니다.
임시 방화벽 접근은 보통 특정 이벤트나 기간을 지원하기 위해 부여됩니다. 프로젝트, 유지보수 작업 시간, 마이그레이션, 테스트 기간, 서드파티 또는 협력업체 업무, 긴급 요청, 단기 비즈니스 요구가 대표적인 예입니다. 그 필요가 해당 이벤트에 연결되어 있으므로, 룰의 라이프사이클도 검토 일자나 종료 일자를 통해 동일하게 연결되어야 합니다.
비즈니스 정당성, 사업부, 룰 소유자, 요청자 및 승인자, 변경 관리 정보, 다음 검토 일자, 만료 일자를 문서화하십시오. 의사결정이 생생할 때 이를 기록해 두면 향후 검토자는 이력을 재구성하는 대신 문서화된 목적과 소유자에서 출발할 수 있습니다. FireMon Security Manager는 팀이 이러한 비즈니스 맥락을 방화벽 룰에 직접 기록할 수 있도록 지원합니다.
만료 일자나 예정된 검토는 누군가의 기억에 의존하지 않는 체크포인트를 만듭니다. 해당 일자가 되면 룰의 소유자와 정당성 정보가 그 접근을 유지할지, 변경할지, 제거할지 판단할 명확한 근거를 제공합니다. 이러한 체크포인트가 없으면 임시 접근은 기본값으로 무기한 유지되는 경향이 있습니다.
반드시 그렇지는 않습니다. FireMon은 만료 일자를 자동 삭제 트리거가 아니라 의도적인 검토 시점으로 다루기를 권장합니다. 일부 접근은 여전히 정당하게 필요할 수 있으며, 확인 없이 제거하면 업무에 지장을 줄 수 있습니다. 목표는 아무도 살펴보지 않아 그대로 유지되는 일이 없도록, 모든 임시 룰에 대해 명시적인 결정을 내리는 것입니다.
네 가지 질문에서 시작하십시오. 누가 이 룰을 요청했는가? 누가 승인했는가? 어떤 비즈니스 요구를 뒷받침했는가? 그 요구는 여전히 존재하는가? 이어서 소유자, 애플리케이션, 프로젝트, 협력업체 관계에 변화가 있었는지 확인하십시오. 룰에 정당성, 소유자, 검토 일자가 문서화되어 있다면, 팀은 이 룰이 무엇을 위한 것인지 아는 사람을 찾는 대신 이러한 질문에 빠르게 답할 수 있습니다.
정당성, 사업부, 소유자, 요청자 및 승인자, 변경 관리 정보, 검토 일자, 만료 일자 등 비즈니스 맥락을 각 룰에 연결할 수 있는 솔루션을 선택하십시오. 또한 룰을 단순한 구성 객체가 아니라 라이프사이클을 갖춘 거버넌스 대상 비즈니스 의사결정으로 다룰 수 있도록 지원해야 합니다. FireMon Security Manager는 이러한 맥락을 방화벽 룰에 문서화할 수 있도록 지원하므로, 팀은 명확한 기록을 바탕으로 임시 접근을 다시 검토할 수 있습니다.