드론의 구조는 드론과 지상의 원격조정자가 각종 데이터를 주고받는 ‘통신부’, 드론의 비행을 조정하는 ‘제어부’, 드론을 날아가게 구동시키는 ‘구동부’, 그리고 카메라 등 각종 탑재 장비들로 구성된 ‘페이로드’의 네 부분으로 나뉜다고 볼 수 있습니다.
※ LTE, WIFI 등 드론 통신방식에 따라 통신부(송신기)에서 제어부(비행제어기)로 위치데이터 등이 이동되고, 제어부의 센서융합기를 통해 자이로센서, 지자기 센서 등 센서값에 대한 측정치를 갖고 있습니다. 이를 비행제어기를 통해 실제 구동부(모터, 프로펠러 등)으로 핀을 통해 데이터를 전달합니다.
드론은 지상에서 드론으로 원격조정(RC) 비행명령어 및 카메라 조작 등 페이로드 제어 신호를 전송하기 위한 상향링크(지상 → 드론)가 필요하고,
비디오, 사진 및 드론의 위치, 비행속도, 배터리 잔량 등의 비행정보를 지상으로 전송하기 위한 하향링크(드론 → 지상)가 필요합니다.
※ GPS 신호는 1.2GHz(혹은 1.5GHz) 주파수 대역으로 수신
[요약]
- 상향링크 : 지상에서 드론으로 페이로드 제어신호를 전송
- 하향링크 : 페이로드, 제어부 등에서 발생한 비행정보를 지상으로 전송
1) 900MHz 및 1.3GHz 주파수 대역
: 900MHz 주파수 대역은 비디오 및 텔레메트리 전송을 위한 하향링크로 사용
- 900MHz 대역은 최근 규격이 확정된 IoT(internet of things)용 WiFi 11ah 무선랜과도 주파수대역이 겹친다. 1.3GHz 주파수 대역 역시 비디오 전송을 위한 하향링크로 사용되는데, 2005년 이후에 쏘아 올린 GPS 위성의 1.2GHz L2 주파수 대역과 가까워서 드론에 탑재된 GPS 수신기에 간섭을 줄 수 있습니다.
2) 2.4GHz 및 5.8GHz 주파수 대역
: 2.4GHz 주파수 대역은 거의 모든 드론이 원격조정 및 페이로드 제어로 사용하는 상향링크입니다.
그러나 2.4GHz는 WiFi, 블루투스, 지그비 등과 주파수대역이 겹치므로 사람이 많이 모이는 공원 등의 지역에서는 드론 비행에 주의해야 합니다. 일부 드론들은 2.4GHz 대역을 비디오 전송 하향링크로 사용합니다. 이 경우, 원격조정 상향링크는 5.8GHz 주파수 대역을 이용합니다. 5.8GHz 주파수 대역은 최근 출시된 드론들이 비디오 및 텔레메트리 전송 하향링크로 사용하는 주파수 대역입니다.
3) WiFi 및 4G/3G
: 드론에 WiFi 수신기를 설치해 스마트폰 WiFi로 직접 드론을 원격조정할 수 있습니다. 드론에 LTE 혹은 WCDMA 송수신기를 설치해 이동통신 네트워크를 통해 스마트폰으로 드론을 원격조정하거나 드론의 비디오 데이터를 지상으로 전송하기도 합니다.
3. GNSS
1. GPS 및 GNSS(Global Navigation Satellite System : 위성항법시스템)
: GPS는 인공위성으로부터 수신기까지 신호가 도달하는 데 걸린 시간(소요시간)을 기준으로 거리를 측정합니다.
GNSS는 크게 1) 위성, 2) 지상의 제어국, 3) 사용자로 구성되어 있습니다. 지상 제어국의 수신장치에서 고도 약 20,000km 중궤도에 위치해 있는 인공위성에서 신호를 받아 수 m 이내의 위치정보를 알아낼 수 있는 것이 GNSS의 기본 원리입니다.
제5조(초경량비행장치의 기준) 법 제2조제3호에서 “자체중량, 좌석 수 등 국토교통부령으로 정하는 기준에 해당하는 동력비행장치, 행글라이더, 패러글라이더, 기구류 및 무인비행장치 등”이란 다음 각 호의 기준을 충족하는 동력비행장치, 행글라이더, 패러글라이더, 기구류, 무인비행장치, 회전익비행장치, 동력패러글라이더 및 낙하산류 등을 말한다.
5. 무인비행장치: 사람이 탑승하지 아니하는 것으로서 다음 각 목의 비행장치
가. 무인동력비행장치: 연료의 중량을 제외한 자체중량이 150킬로그램 이하인 무인비행기, 무인헬리콥터 또는 무인멀티콥터*
나. 무인비행선: 연료의 중량을 제외한 자체중량이 180킬로그램 이하이고 길이가 20미터 이하인 무인비행선
-> 여기서드론은 일반항공기처럼 날개가 고정되어있는 고정익과, 로터를 갖고있는 회전익 으로 분류되며,멀티콥터(Multi Copter)란 여러 개의 로터(Rotor)를 가진 비행체로, 로터의 수에 따라 아래처럼 불리게 됩니다.
올바른 값과, 올바르지 않은 값을 입력값으로 주어, 도출된 결과(올바른 결과가 도출되었는지)를 보고 판단하는 방식이 Blackbox testing이다.
블랙박스 테스트는 소프트웨어가 수행할특정 기능을 알기 위해서각기능이완전히 작동되는 것을 입증하는 테스트로,기능 테스트라고도 한다.
사용자의 요구사항 명세를 보면서 테스트하는 것으로, 주로 구현된 기능을 테스트한다.
소프트웨어인터페이스에서 실시되는 테스트이다.
부정확하거나 누락된 기능, 인터페이스 오류, 자료 구조나 외부 데이터베이스 접근에 따른 오류, 행위나 성능 오류, 초기화와 종료 오류 등을 발견하기 위해 사용되며,테스트 과정의 후반부에 적용된다.
2. Whitebox Testing(화이트박스 테스트)
응용 프로그램의 내부 구조와 로직(Logic)을 검사하는 테스트방식으로, 내부 소스코드를 테스트하는 방식을 예로 들 수 있다.
- 화이트박스 테스트는 소프트웨어, 모듈 등의 소스코드를 오픈시킨 상태에서논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법이다.
화이트박스 테스트
화이트박스 테스트는 설계된 절차에 초점을 둔구조를 분석하는 테스트며, 주로 테스트 과정의 초기에 적용된다.
모듈 안의 작동을직접 분석한다.
소스코드(모듈)의 모든 문장을한 번 이상 실행함으로써 수행된다.
프로그램의 제어 구조에 따라 선택, 반복 등의 분기점 부분들을 수행함으로써 논리적 경로를 제어한다.
이 두가지 테스트방식은 단순 소프트웨어를 테스트할 때 뿐만 아니라, 보안에서도 쓰일 수 있다.
가령 홈페이지, 모바일 앱 취약점 점검 등 기능적인 부분을 테스트 할 때에는 Blackbox Testing 방식이라고 볼 수 있으며, 직접 홈페이지, 모바일 앱의 소스코드를 분석하여 논리구조(구성)를 이해하고 보안 취약점이 존재하는지 테스트 할 때에는 Whitebox Testing 이라고 볼 수 있다.
- SQL, NoSQL, OS 및 LDAP 삽입과 같은 삽입성 보안약점은 신뢰할 수없는 데이터가 명령 또는 쿼리의 일부로 인터프리터에 전송 될 때 발생합니다. 공격자 데이터는 인터프리터가 의도하지 않은 명령을 실행하거나 적절한 권한 없이 데이터에 액세스하도록 속일 수 있습니다.
시나리오 # 1 : 애플리케이션은 다음과 같은 취약한 SQL 호출을 구성 할 때 신뢰할 수없는 데이터를 사용합니다. 시나리오 # 2 : 마찬가지로 프레임 워크에 대한 애플리케이션의 맹신 신뢰로 인해 여전히 취약한 쿼리가 발생할 수 있습니다 (예 : Hibernate Query Language (HQL)). 두 경우 모두 공격자는 브라우저에서 'id'매개 변수 값을 수정하여 '또는'1 '='1을 전송합니다. 예 : 이렇게하면 accounts 테이블의 모든 레코드를 반환하도록 두 쿼리의 의미가 변경됩니다. 더 위험한 공격은 데이터를 수정 또는 삭제하거나 저장 프로 시저를 호출 할 수도 있습니다.
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
- 공격자는 암호화를 직접 공격하는 대신 키를 훔치고, 중간자 공격을 실행하거나, 전송 중이거나 브라우저와 같은 사용자 클라이언트에서 서버에서 일반 텍스트 데이터를 가로챕니다.
- 가장 일반적인 결함은 단순히 민감한 데이터를 암호화하지 않는 것입니다. 암호화가 사용되면 약한 키 생성 및 관리, 약한 알고리즘, 프로토콜 및 암호 사용이 일반적이며 특히 약한 암호 해싱 저장 기술의 경우에 노출되기 쉽습니다. 전송중인 데이터의 경우 서버 측 약점은 주로 감지하기 쉽지만 미사용 데이터에는 어렵습니다.
* 데이터가 일반 텍스트로 전송되는지 확인필요(HTTP, SMTP 및 FTP와 같은 프로토콜과 관련이 있음). 외부 인터넷 트래픽은 특히 위험합니다. 로드 밸런서, 웹 서버 또는 백엔드 시스템 간의 모든 내부 트래픽을 확인합니다.
* 기본적으로 또는 이전 코드에서 사용되는 오래되거나 취약한 암호화 알고리즘이 있습니까?
* 기본 암호화 키가 사용 중이거나 약한 암호화 키가 생성 또는 재사용되었거나 적절한 키 관리 또는 순환이 누락 되었습니까?
* 암호화가 적용되지 않습니까? 예를 들어 사용자 에이전트 (브라우저) 보안 지침 또는 헤더가 누락 되었습니까?
* 사용자 에이전트 (예 : 앱, 메일 클라이언트)가 수신 된 서버 인증서가 유효한지 확인하지 않습니까?
4) A4 : 2017-XML External Entities (XXE) (XML 외부 엔터티(XXE))
- 인증 된 사용자가 수행 할 수 있는 작업에 대한 제한이 종종 제대로 시행되지 않습니다. 공격자는 이러한 결함을 악용하여 다른 사용자의 계정에 액세스하고, 중요한 파일을 보고, 다른 사용자의 데이터를 수정하고, 액세스 권한을 변경하는 등의 무단 기능 및 데이터에 액세스 할 수 있습니다.
- 보안 구성 오류가 가장 일반적으로 발생하는 문제입니다. 이는 일반적으로 안전하지 않은 기본 구성, 불완전하거나 임시 구성, 개방형 클라우드 스토리지, 잘못 구성된 HTTP 헤더 및 민감한 정보가 포함 된 자세한 오류 메시지의 결과로 발생합니다. 모든 운영 체제, 프레임 워크, 라이브러리 및 애플리케이션을 안전하게 구성해야 할뿐만 아니라 적시에 패치 / 업그레이드를 해야합니다.
시나리오 # 1 : 애플리케이션 서버는 프로덕션 서버에서 제거되지 않은 샘플 애플리케이션과 함께 제공됩니다. 이러한 샘플 애플리케이션에는 공격자가 서버를 손상시키는 데 사용하는 알려진 보안 결함이 있습니다. 이러한 응용 프로그램 중 하나가 관리 콘솔이고 기본 계정이 변경되지 않은 경우 공격자는 기본 암호로 로그인하고 인계합니다.
시나리오 # 2 : 서버에서 디렉토리 목록이 비활성화되지 않습니다. 공격자는 단순히 디렉토리를 나열 할 수 있음을 발견합니다. 공격자는 컴파일 된 Java 클래스를 찾아 다운로드하여 코드를 보기 위해 디 컴파일 및 리버스 엔지니어링 합니다. 그런 다음 공격자는 애플리케이션에서 심각한 액세스 제어 결함을 발견합니다.
시나리오 # 3: 응용 프로그램 서버의 구성을 통해 스택 추적과 같은 자세한 오류 메시지를 사용자에게 반환 할 수 있습니다. 이는 취약한 것으로 알려진 구성 요소 버전과 같은 민감한 정보 또는 근본적인 결함을 잠재적으로 노출합니다.
시나리오 # 4 : 클라우드 서비스 공급자는 다른 CSP 사용자가 인터넷에 공개하는 기본 공유 권한을 가지고 있습니다. 이를 통해 클라우드 스토리지에 저장된 민감한 데이터에 액세스 할 수 있습니다.
- XSS 결함은 애플리케이션이 적절한 유효성 검사 또는 이스케이프없이 새 웹 페이지에 신뢰할 수 없는 데이터를 포함하거나 HTML을 만들 수있는 브라우저 API를 사용하여 사용자가 제공 한 데이터로 기존 웹 페이지를 업데이트하거나 자바 스크립트, XSS를 통해 공격자는 피해자의 브라우저에서 스크립트를 실행하여 사용자 세션을 가로채거나 웹 사이트를 손상 시키거나 사용자를 악성 사이트로 리디렉션 할 수 있습니다.
[XSS의 3가지 종류]
* Reflected XSS : 응용 프로그램 또는 API는 HTML 출력의 일부로 유효성 검사 및 이스케이프 처리되지 않은 사용자 입력을 포함합니다. 공격이 성공하면 공격자가 피해자의 브라우저에서 임의의 HTML 및 JavaScript를 실행할 수 있습니다. 일반적으로 사용자는 악성 워터 링 홀 웹 사이트, 광고 등과 같이 공격자가 제어하는 페이지를 가리키는 일부 악성 링크와 상호 작용해야합니다.
* Stored XSS : 응용 프로그램 또는 API는 나중에 다른 사용자 또는 관리자가 볼 수 있는 삭제되지 않은 사용자 입력을 저장합니다. 저장된 XSS는 종종 높거나 중요한 위험으로 간주됩니다.
* DOM XSS: 페이지에 공격자가 제어 할 수 있는 데이터를 동적으로 포함하는 JavaScript 프레임워크, 단일 페이지 애플리케이션 및 API는 DOM XSS에 취약합니다. 이상적으로는 애플리케이션이 공격자가 제어 할 수있는 데이터를 안전하지 않은 JavaScript API로 보내지 않습니다.
일반적인 XSS 공격에는 세션 도용, 계정 탈취, MFA 우회, DOM 노드 교체 또는 손상 (트로이 목마 로그인 패널 등), 악성 소프트웨어 다운로드, 키 로깅 및 기타 클라이언트 측 공격과 같은 사용자 브라우저에 대한 공격이 포함됩니다.
시나리오 # 1 : 애플리케이션이 유효성 검사 또는 이스케이프없이 다음 HTML 스니펫의 구성에 신뢰할 수없는 데이터를 사용합니다 . 공격자는 브라우저에서 'CC'매개 변수를 다음과 같이 수정합니다. 이 공격으로 인해 피해자의 세션 ID가 공격자의 웹 사이트로 전송됩니다. 공격자가 사용자의 현재 세션을 가로 채도록 허용합니다. 참고 : 공격자는 XSS를 사용하여 애플리케이션이 사용할 수 있는 자동화 된 CSRF (Cross-Site Request Forgery) 방어를 무력화 할 수 있습니다.
- 라이브러리, 프레임 워크 및 기타 소프트웨어 모듈과 같은 구성 요소는 애플리케이션과 동일한 권한으로 실행됩니다. 취약한 구성 요소가 악용되는 경우 이러한 공격은 심각한 데이터 손실이나 서버 탈취를 촉진 할 수 있습니다. 알려진 취약성이 있는 구성 요소를 사용하는 애플리케이션과 API는 애플리케이션 방어를 약화시키고 다양한 공격과 영향을 미칠 수 있습니다.
시나리오 # 1 : 구성 요소는 일반적으로 응용 프로그램 자체와 동일한 권한으로 실행되므로 구성 요소의 결함으로 인해 심각한 영향을 받을 수 있습니다. 이러한 결함은 우발적 (예 : 코딩 오류) 또는 의도적 (예 : 구성 요소의 백도어) 일 수 있습니다. 발견 된 악용 가능한 구성 요소 취약점의 몇 가지 예는 다음과 같습니다.
* 서버에서 임의의 코드를 실행할 수 있는 Struts 2 원격 코드 실행 취약점 인 CVE-2017-5638 이 심각한 위반으로 인해 비난을 받았습니다.
* 사물 인터넷 (IoT) 은 패치하기가 어렵거나 불가능한 경우가 많지만 패치 적용의 중요성은 클 수 있습니다 (예 : 생체 의료 기기).
- 불충분 한 로깅 및 모니터링은 사고 대응과의 누락 또는 비효율적 인 통합과 결합되어 공격자가 시스템을 추가 공격하고, 지속성을 유지하고, 더 많은 시스템으로 피벗하고, 데이터를 변조, 추출 또는 파괴 할 수 있습니다. 대부분의 침해 연구에 따르면 침해를 감지하는 데 걸리는 시간은 200 일 이상이며 일반적으로 내부 프로세스 또는 모니터링이 아닌 외부 당사자가 감지합니다.
시나리오 # 1 : 소규모 팀이 운영하는 오픈 소스 프로젝트 포럼 소프트웨어가 소프트웨어 결함을 사용하여 해킹 당했습니다. 공격자들은 다음 버전과 모든 포럼 콘텐츠가 포함 된 내부 소스 코드 저장소를 삭제했습니다. 소스는 복구 할 수 있지만 모니터링, 로깅 또는 경고의 부족으로 인해 훨씬 더 심각한 침해가 발생했습니다. 이 문제로 인해 포럼 소프트웨어 프로젝트가 더 이상 활성화되지 않습니다.
시나리오 # 2 : 공격자는 공통 암호를 사용하여 사용자를 검색합니다. 이 비밀번호를 사용하여 모든 계정을 인계받을 수 있습니다. 다른 모든 사용자의 경우가 스캔은 하나의 잘못된 로그인 만 남겨 둡니다. 며칠 후 다른 암호로이 작업을 반복 할 수 있습니다.
시나리오 # 3: 미국의 한 주요 소매 업체가 첨부 파일을 분석하는 내부 맬웨어 분석 샌드 박스를 보유한 것으로 알려졌습니다. 샌드 박스 소프트웨어가 잠재적으로 원치 않는 소프트웨어를 감지했지만 아무도이 감지에 응답하지 않았습니다. 샌드박스는 외부 은행의 사기성 카드 거래로 인해 위반이 감지되기 전에 한동안 경고를 생성했습니다.
: 데이터 이용을 활성화하는「개인정보 보호법」,「정보통신망 이용촉진 및 정보보호 등에 관한 법률(정보통신망법)」,「신용정보의 이용 및 보호에 관한 법률(신용정보법)」등 3가지 법률을 통칭합니다.
핵심적인 내용은, 개인정보를 데이터로 활용 가능하도록 허용한다는 것입니다.
일반인의 개인정보란 이름, 생년월일, 주소, 주민등록번호 등 민감한 정보뿐만이 아니라 개인이 선호하는 장소, 음식, SNS 정보 등 개인의 멀티미디어 데이터 또한 무한히 많을 것입니다.
예를 들어개인정보 데이터를 활용할 수 있게 된다면, 정부나 공공기관에서 개인들의 정보를 분석하기 위해 SNS로 많은 사람들이 방문하는 장소(예로 유명한 카페, 음식점 등)를 수집.분석하여, 해당 장소로의 교통 서비스(버스편 추가, 지하철 노선 확장 등)를 제공할 수 있음으로써, 삶의 질을 한 층 더 높일 수 있습니다. (조금 더 삶의 질이 향상되는 멋진 예시가 떠오르지 않아 죄송하네요ㅠ)
요약하면 이런 개인의 데이터를 정부, 기업 등에서 수집하고 분석하여 보다 나은 양질의 서비스를 제공할 수 있도록 데이터로 활용할 수 있게 된다는 뜻입니다.
장점?
이렇게 개인정보에 대한 데이터를 활용하게 되면 국민의 세금을 보다 실용적으로 사용 할 수 있을 것입니다.
또한 이런 개인정보도 종류가 무한한 만큼, 이를 수집하고 분석하여 통계내는 새로운 서비스나 일자리가 생기게 될 것입니다.
위에서 개인정보 데이터 활용에 대한 부분을 살펴보았고, 이제 데이터 3법 개정안의 핵심내용을 살펴보겠습니다.
1. '가명정보' 도입
: 개인정보의 체계는 '개인정보, 가명정보, 익명정보' 로 구분되며 개념마다 역할 및 취급사항도 다르게 규정됩니다. 가명정보란 특정 개인을 알아볼 수 없도록 처리한 정보로, 익명정보에 비해 많은 정보를 담고있어 데이터 활용에 유리해집니다.
2. 개인정보보호 체계 효율화 및 일원화
: 기존의 개인정보 보호법을 다루는 정부 기관들은 '행정안전부, 방송통신위원회, 금융위원회, 개인정보보호위원회' 등 이었습니다. 이렇게 법은 하나인데 다루는 기관들이 많으므로 각기 해석과 규제의 중복성이 발생하는 등 문제가 있어, 개정안에서 법 제도 및 감독 기관을 개인정보보호법 - 개인정보보호위원회로 일원화 하였습니다.
3. 데이터보안 강화 및 처벌 조항 강화
: 개인정보는 활용가치가 큰 만큼, 그만큼 유출되었을 때 사회적 문제를 야기할 수 있을만큼 민감한 데이터입니다. 따라서 이에 대한 보안을 강화하고, 처벌조항이 강화되어 질 것입니다.
(EU의 개인정보보호법(GDPR)이 강화된 것으로, 우리나라도 개인정보 사고 발생 시 규제와 처벌 등 강화될 것으로 보입니다.)
Stateful Inspection은 1세대의 Packet filtering 방식과 2세대의 Application Gateway 방식의 장점을 혼합한 3세대 방화벽 기술로, 네트워크 트래픽과 관련된 모든 통신채널을 상태목록에 유지시킨 후 누가, 언제 사용하였는지 또는 거부당했는지, 어떤 경로를 통해 외부에 접속하였으며 돌아왔는지 분석하고 패킷의 액세스 여부를 결정하는 기능입니다.
이 방식은 패킷으로부터 받은 정보와 전송상태, 연결상태, 타 Application들과의 관계 및 패킷의 Layer를 면밀하게 검사하는 구조를 가집니다.
2) Black & White list 기반 Filtering
화이트리스트 방식은 안전하다고 증명된 것만을 정책적으로 허용하고 나머지는 차단함으로써 내부 네트워크를 안전하게 유지시키는 방식이며,
블랙리스트 방식은 위협으로 인증된 것만을 관리자가 지정 및 차단하여 내부 네트워크를 안전하게 유지시키는 보안 방식 입니다.
어느것이 더 좋다라고는 말할 수 없지만(상황에 따라 다를 수 있음), 대체적으로 화이트리스트 기반의 정책을 적용하는 것이 이후 추가적인 방화벽 정책 수립 시 관리자의 실수로 인한 추가적인 보안홀(Hole)을 막을 수 있습니다.
3) NAT(Network Address Translation) 기능 지원 : Static/ Dynamic NAT, Excluded NAT, NAT Traversal
NAT 기능은 네트워크에서 외부망과 내부망을 나눠주는 기능을 가능하게 합니다. 내부망 그대로의 주소를 외부망으로 가져갈 수 없으므로 이 NAT를 통해 외부망 주소로 바꿔서 나가게 됩니다.
즉 네트워크의 주소를 변환하는 기능으로 방화벽의 대표적인(주요) 기능중 하나로 볼 수 있습니다.
이 NAT기능의 장점은 1) 인터넷의 공인IP 주소를 절약할 수 있으며(공인IP 한개로 내부망에서 여러 IP를 사용할 수 있음), 2) 공공네트워크(인터넷)에 연결되는 사용자들의 고유한 개인 사설망을 외부위협으로부터 보호할 수 있게 됩니다.
> NAT에 대한 보다 자세한 설명은 다음의 블로그에서 잘 나와있는 것 같아 아래의 링크를 참고하면 좋을 것 같습니다.
방화벽에서 스케줄링을 통해 일/주/월/년 등 다양한 시간단위로 정책을 스케줄링할 수 있도록 하는 기능입니다.
방화벽 정책 수립 시, 대부분 일반적으로는 차단정책(ANY-ANY-DENY)을 기반으로 만들게 됩니다.
(action은 ALLOW(허가)/DENY(부인) 으로 구분)
위의 ANY-ANY-DENY로 하게되면 일반적으로 ACL(Access Control List)의 가장 하단에 위치하여, 상단 방화벽 정책 외의 나머지는 전부 막도록 합니다.
왜냐하면 위의 2) 에서 잠깐 언급했던것과 같이, 블랙리스트 기반의 위협 IP에 대한 보안정책을 실시간으로 만들기에는 관리자가 제약이 따르기 때문인데요. 이를 위해 대부분은 처음부터 전부 차단을 해놓고, 예외적으로 필요한 부분만을 열어주는 화이트리스트 기반의 정책을 수립하게 됩니다.
이 때, 잠깐 하루정도만 예외적으로 열었다가 다음날 다시 닫아야 하는 정책이 생기는 경우도 있습니다. 이런 경우에는 관리자가 기억해주면 좋겠지만 혹여 다시 차단하는것을 기억하지 못하여 깜빡한채로 남겨질 수도 있기 때문에 보안홀로 발생할 수 있게됩니다. 이러한 부분을 커버하기 위해 일/주/월/년 등 시간단위로 스케줄링하여 정책을 만들 수 있게하는 것이 방화벽에서 지원하는 기능 중 하나입니다.
5) 가용성 보장 : Active-Active, Active-Standby HA (with/without L4 switch)
이 기능들을 설명하기 전에, 방화벽의 또 하나 중요하게 다루는 부분이 이중화에 대한 개념입니다.
사실 방화벽 뿐만 아니라 다른 보안장비들도 이중화하는것은 필요한데요, 우선 이 이중화에 대해 간단히 설명하고 기능들을 설명하도록 하겠습니다.
이중화를 간단히 설명하면, 동일한 보안장비(방화벽) 2대를 두고 운용하다가, 그 중 1개의 방화벽이 어떤 장애로 인하여 기능을 상실하게 되면 이중화된(연결된) 다른 방화벽이 대신하여 그 기능을 수행하는 것입니다.
이렇게 이중화를 하는 방식에는 기본적으로 Active-Active, Active-Standby 등이 있는데요.
Active/Active는 양쪽 장비 모두가 트래픽을 처리하고 부하 분산이 가능하며, Security Context 에서만 지원됩니다.
Active/Standby에서는 한 장비(Active)에서만 트래픽을 처리하다가 문제발생시, Standby 장비가 Active장비의 기능을 대체하여 사용하는 방식입니다.
Stateful 이중화: 주 장비(Active)가 현재의 세션정보를 Standby 장비에게 전달하고, 장애가 발생해도 사용자들의 접속이 끊어지지 않는다고 합니다.
이렇게 이중화 관련하여 failover, loadbalancing 등의 개념들이 있는데요.
방화벽, 서버 등 이중화를 위해서는 failover-link로 연결되는데 이 Failover(시스템 대체 작동)는 평소 사용하는(Active) 방화벽과 이중화된 Standby 방화벽을 가지고 있다가 사용중이던 방화벽이 장애로 사용이 어렵게 되었을 경우 Standby방화벽으로 그 일을 대신 처리하게 해서 무정지 시스템을 구축하게 해주는 것을 의미합니다.
loadbalancing(부하균형)은 이렇게 두 개 이상의 방화벽이 일을 분담처리 해 방화벽에 가해지는 네트워크 트래픽을 분산시켜주는 것을 말합니다. 병렬로 트래픽을 처리하도록 하여 방화벽에 걸리는 부하의 정도 균형을 잡아줍니다.
한 방화벽에 너무 많은 트래픽 과부하가 걸리거나 너무 적게 걸려 낭비되지 않도록 작업을 적절히 분배하고, 필요한 경우에는 작업을 한 방화벽에서 다른 방화벽으로 이동시키기도 합니다.
보통은 사용자가 방화벽에 부하가 걸릴만한 상황을 고려하여 조건을 설정하고 조건이 충족된 상황에서 다른 방화벽이 트래픽을 분담처리하도록 합니다.
6) 중복정책 검색 기능
관리자가 방화벽 정책을 수립하다가 관리하는 정책이 너무 많아지거나 혹은 관리자가 변경되는 경우처럼,
이전에 정책을 만들어 놓고 똑같은 정책(혹은 범위만 다른 유사한)을 만들게 되기도 합니다. 이는 쓸데없이 방화벽정책의 수만 증가시켜 관리자로 하여금 정책 모니터링에 어려움이 있을 수 있으므로 방화벽 자체적으로 중복되는 정책에 대해서는 검색하는 기능이 있어 관리자에게 알려줄 수 있는 기능이 있습니다. (확인하고 지우는 건 관리자 몫이겠죠?
이렇게 위의 일부 기능에 대해 세부적으로 살펴보았는데 이 외에도 방화벽의 기능들은 훨씬 많으니 관심이 있다면 방화벽 솔루션 기업들의 세부 규격이나 성능, 기능사항들을 직접 보시는걸 추천드립니다.
여기에 차세대 방화벽의 추가적인 기능은 아래와 같다고 보입니다.
1) Application 제어 : 이전 세대의 UTM 방화벽은 IP, PORT 를 기반으로 차단하는 정책을 수립했다면, 이제는 특정 애플리케이션(트위터, 페이스북, G마켓, 쿠팡 등) 기반으로도 차단하는 것이 가능합니다.
이 애플리케이션 제어기능은 세부적으로도 나눌 수 있는데, 예를 들어 페이스북 페이지까지만 볼 수 있게 정책을 만드는것도 가능하며, 사용자의 로그인까지 가능하게 하거나, 글쓰는 것을 막는 기능까지도 가능합니다.
2) 사용자 ID 기반 정책 : 위에서 정의한 것처럼 방화벽 정책을 만들 때, IP, PORT 등으로 만드는 정책이 기본적이나 이는 내부 기업에서 인사이동 등으로 인한 사용자의 IP가 변하거나 할 때 유동적이지 못합니다. 하여, 사용자의 ID는 기업 내부에서는 어떻게보면 고유한 값이므로, 이 사용자ID를 기반으로 정책을 수립하여 세분화된 보안정책을 만드는 것도 가능합니다.
3) DLP(Data Loss Prevention) : 내부 정보 유출방지에 대한 기능으로, 데이터의 흐름을 감시해서 기업내부의 중요한 정보가 외부로 유출되는 것을 막는 기능인데, 이제 방화벽에도 이런 기능이 추가되었나봅니다..
이 DLP 와 관련되어서는 기존에 이미 DLP솔루션이라 하여 다양한 제품들이 있으니 참고하시면 좋을듯합니다.
