외부에서 접속하는 서버를 운영할 때는 해당 서버에서 전달되는 보고를 다루는 방식에도 주의가 필요합니다. 서버나 소프트웨어의 오류, 설정 변경, 침해 가능성 등으로 인해 보고가 실제 상태를 충분히 나타내지 못할 수 있습니다.

BASTION에서는 DMZ의 Agent가 보내는 정보를 검증하고 허용할 작업 범위를 제한하는 설계를 중시합니다. 이 글에서는 그 설계 방향과 운영상 확인할 사항을 소개합니다.

1. 보고 내용을 검증 대상으로 다루기 #

Agent의 보고를 받았다는 사실만으로 그 내용이 충분히 확인되었다고 볼 수는 없습니다. 운영 환경에 맞는 확인을 거쳐 판단에 활용할 수 있는 정보인지 검토해야 합니다.

BASTION은 보고 수신과 방어 판단의 역할을 정리하고, 검증 결과를 바탕으로 대응하는 설계 방향을 채택하고 있습니다.

2. 작업 범위 제한하기 #

Agent가 사용할 수 있는 기능과 작업 대상은 도입 환경의 요구 사항에 맞춰 제한합니다. 필요한 역할과 권한을 정리하고 기존 운영에 미치는 영향을 확인합니다.

권한 제한은 보호 대책의 하나입니다. 그것만으로 침해나 잘못된 작업으로 인한 모든 영향을 막을 수 있다고 보지는 않습니다.

3. 정보를 얻을 수 없는 상태 구분하기 #

보고가 도착하지 않거나 내용이 오래되었거나 확인에 필요한 정보가 부족한 상태는 문제가 없다는 증거가 되지 않습니다. 판단과 함께 실제로 관측이 이루어지고 있는지도 확인합니다.

부족한 정보를 파악할 수 있도록 하여 운영자의 확인과 조치로 이어지게 하는 것을 중시합니다.

4. 정상적인 이용에 미치는 영향도 확인하기 #

방어를 위한 대응이라도 대상을 잘못 지정하면 정상적인 이용자와 업무에 영향을 미칩니다. 대응 대상 범위, 기록 방법, 운영자가 확인하고 조치하는 절차를 함께 정리하는 것이 중요합니다.

자동화할 범위와 필요한 확인 방법은 도입 환경의 조건에 따라 검토합니다.

5. 운영 기록과 방어 효과 구분하기 #

BASTION은 자사 환경의 관측 정보와 대응 이력을 확인하면서 개선을 이어가고 있습니다. 다만 이상이나 오차단이 관측되지 않았다는 사실만으로 침해가 발생했을 때의 방어 효과까지 확인되었다고 할 수는 없습니다.

이용 조건에 맞춰 검증하고, 확인된 범위와 아직 확인하지 못한 범위를 구분합니다.

6. 도입 시 확인 사항과 공개 범위 #

도입 시에는 수집할 수 있는 정보, 접속 조건, 허용할 작업, 운영자의 확인 절차를 정리합니다. 구성과 평가 범위는 대상 환경과 요구 사항에 맞춰 개별 견적을 제공합니다.

이 글은 설계 방향을 설명하며 검증 알고리즘, 제어 조건, 내부 연결 구성, 고객의 운영 정보는 공개하지 않습니다. 현재 기능과 검증 현황은 BASTION 서비스 소개 페이지를 참고해 주세요.