08권한 부여와 접근 제어권한 부여와 접근 제어

통합 정책 안의 Mobile Access 개요

Mobile Access를 Unified Policy(통합 정책)에 포함하면, Mobile Access Portal, Capsule Workspace, 온디맨드(on-demand) 클라이언트에 관한 규칙을 모두 Access Control Policy 한곳에서 다루게 됩니다. Access Control Rule Base에서 이런 규칙을 만들 수 있습니다.

Protection Level, Secure Workspace, Endpoint Compliance 같은 Mobile Access 기능도 그대로 함께 적용됩니다.

통합 정책에서 Mobile Access 구성하기

통합 정책에 Mobile Access를 넣을 때 지켜야 할 핵심 규칙들이 있습니다.

예컨대 Application Control 용으로 정의한 응용 객체는 Mobile Access 규칙에서 지원되지 않 습니다. - Security Gateway에서 Mobile Access를 켜면, 그 게이트웨이는 자동으로 RemoteAccess VPN Community 에 추가 됩니다. 규칙의 VPN 열에 이 Community를 넣거나, Any를 두어 Mobile Access Security Gateway에 적용되게 합니다. 만약 게이트웨이를 VPN Community에서 제거했다면, VPN 열에는 반드시 Any가 들어가야 합니다. - 규칙을 특정 사용자·네트워크에 적용하려면 Source 나 Destination 에 Access Role 을 씁니다. Access Role로 Mobile Access나 그 밖의 원격 접근을 표현할 수도 있습니다.

Unified Access Policy에서 Mobile Access 규칙 만들기

Mobile Access 규칙은 Access Control Policy 에서 다음 요건에 맞춰 만듭니다.

VPN·Services·Action 등 나머지 열의 규칙은 다음과 같습니다.

Unified Access Policy에서 Mobile Access 응용 쓰기

Unified Access Policy에서 Mobile Access 응용을 쓰려면, 그것을 SmartConsole 에서 Mobile Application 으로 정의하거나 SmartDashboard > Mobile Access 탭 에서 정의해야 합니다.

URL Filtering 응용 같은 다른 종류의 응용 객체는 Mobile Access와 무관합니다. 예를 들어 Facebook을 Mobile Access의 웹 응용으로 허용 하려면, URL Filtering의 Facebook 응용을 쓰는 게 아니라 새 Web Application 을 만들고 Facebook의 URL을 지정 해야 합니다. URL Filtering의 Facebook 응용은 Mobile Access용이 아니기 때문입니다.

Access Control Policy용 Mobile Application 만들기

Access Control Policy에서 쓸 Mobile Application 객체를 만드는 방법입니다.

원격 접근용 Access Role

원격 접근 연결을 다루는 규칙은 Access Control Rule Base에서 이렇게 만듭니다.

예시 — 원격 접근 사용자가 조직의 SMTP 서버(SMTP_SRV)에 접근하도록 허용하려면 다음 규칙을 만듭니다.

통합 정책에 Mobile Access 포함시키기

Unified Access Policy에 Mobile Access 규칙을 다 구성했으면, 이제 Security Gateway가 Unified Access Policy를 쓰도록 설정 합니다.

Mobile Access Security Gateway가 Unified Access Policy를 쓰게 하는 방법은 이렇습니다.

레이어에서 Access Control 기능 켜기

Ordered Layer 에서 Mobile Access를 켜는 방법입니다.

Inline Layer 에서 Mobile Access를 켜는 방법입니다.

Unified Access Policy에 Mobile Access를 넣을 때 알아 두어야 할 요소들이 있습니다 — 레이어를 어떻게 쓸지, 규칙의 내용이 정책에 어떻게 영향을 주는지, 규칙 순서가 정책에 어떻게 영향을 주는지 입니다.

레이어 관련 모범 사례

Mobile Access 정책을 쉽게 관리하려면 Mobile Access 규칙을 Inline Layer 로 묶기를 권장 합니다.

Inline Layer를 효과적으로 쓰려면, 메인 레이어에 부모 규칙(parent rule) 을 정의합니다. 이 부모 규칙은 모든 Mobile Access 트래픽과 매칭되어 트래픽을 Inline Layer로 보냅니다. 부모 규칙의 Source 열에는 모든 Mobile Access 클라이언트 유형(또는 트래픽)을 담은 Access Role 이 필요합니다. 규칙의 Action 열에 Inline Layer 를 넣으면, 그 아래에 Inline Layer가 자동으로 생기고 그 규칙이 부모 규칙이 됩니다.

다음은 Inline Layer를 활용한 Rule Base 예시입니다.

Ordered Layer와 함께 쓰는 Mobile Access

Ordered Layer 를 쓴다면, 어떤 Ordered Layer 안에든 Mobile Access Inline Layer를 둘 수 있습니다. 끝에는 Cleanup 규칙을 둡니다.

모든 Mobile Access 트래픽을 Mobile Access Inline Layer로 보내는 규칙을 만드는 방법입니다.

Inline Layer 안에서 규칙을 구성하는 방법입니다.

규칙 순서 모범 사례 — bypass 규칙

여러 Ordered Layer를 쓸 때는, Mobile Access 레이어보다 앞선 모든 레이어 에 Mobile Access 트래픽용 bypass 규칙 을 만들 어야 합니다. 예를 들어 Mobile Access Inline Layer가 세 번째 레이어에 있다면, 첫 번째와 두 번째 Ordered Layer에 bypass 규칙을 둬야 합니다.

bypass 규칙은 그 레이어에서 Mobile Access 트래픽과 매칭되어 트래픽을 허용 합니다. 그러면 트래픽이 다음 레이어로 넘어가, 마침내 Mobile Access Inline Layer에 도달합니다. bypass 규칙을 만들려면 Source 열에 모든 Mobile Access 사용자를 담은 Access Role, Action 열에 Accept 를 씁니다.

규칙 작성 모범 사례

규칙 순서 모범 사례 — 응용 규칙이 서비스 규칙보다 위에

Unified Access Policy에서는, 응용을 권한 부여하는 Mobile Access 규칙을, 관련 서비스를 다루는 규칙보다 위에 두어야 합니다. 예컨대 웹 응용을 허용하는 규칙을 HTTP/HTTPS를 허용·차단하는 규칙보다 위에 두어야 합니다. HTTP/HTTPS 규칙이 먼저 오면, 사용자는 포털·Capsule Workspace에서 Mobile Access 웹 응용을 보지 못하고 접근도 못 합니다.

예를 들어 다음 Rule Base는 웹 기반 Mobile Access 응용인 OWA(Outlook Web Access) 를 허용하면서 HTTPS 트래픽도 허용합니다. HTTPS 서비스와 Mobile Access HTTPS 응용을 모두 올바르게 허용하는 방식 입니다.

여기서 HTTPS 위에서 도는 OWA를 포함해 Mobile Access 응용을 허용하는 규칙 2.1 이, 모든 HTTPS 트래픽을 허용하는 규칙 3 보다 위에 있습니다. 만약 HTTPS를 허용하는 규칙 3을 Mobile Access 규칙보다 위에 두면, 사용자는 포털·Capsule Workspace에서 OWA 웹 응용을 보지 못하고 접근도 못 합니다. Mobile Access 응용을 권한 부여하려면 반드시 Services & Applications 열에 Mobile Access 응용을 써야 합니다.

Native Application의 경우

Native application 을 쓰는 다음 시나리오에서는 — Native application이 Rule Base의 Inline Layer 에 있고, 그 Native application 구성의 Authorized Locations 탭에 Any가 들어 있다면 — Inline Layer의 부모 규칙 의 Services & Applications 열에 다음 중 하나가 들어 있어야 합니다.

Protection Level 은 연결성과 보안 사이의 균형을 맞춘, 미리 정의된 보안 설정 묶음 입니다. 이를 통해 Mobile Access 관리자는 요건이 비슷한 응용 그룹에 대해 응용 보호를 한 번에 정의할 수 있습니다.

Mobile Access에는 기본으로 세 가지 Protection Level — Normal, Restrictive, Permissive — 이 제공됩니다. 새 Protection Level을 만들거나 기존 것의 보호 설정을 바꿀 수 있습니다.

Protection Level 사용하기

Protection Level은 대부분의 Mobile Access 응용 유형 정의에 포함 할 수 있습니다. 각 응용에는 하나의 Protection Level을 연결할 수 있으며, 모든 native 응용에는 하나의 공통 Protection Level 을 지정할 수 있습니다.

응용을 정의할 때, 응용 객체의 Protection Level 페이지에서 이 응용에 접근하기 위한 보안 요건(Security Requirements for Accessing this Application) 으로 다음 중 하나를 고릅니다.

Protection Level 정의하기

Mobile Access 탭 에서 Protection Level 페이지로 가는 방법입니다.

Mobile Access 응용 에서 Protection Level 페이지로 가는 방법입니다.

Protection Level의 설정을 구성하는 방법입니다.

배경

제3자 벤더를 통한 Mobile Device Management(MDM) 지원은, 내부 자원에 접근하는 기기에 통합 보안 정책을 강제 합니다. 조직 보안 정책을 준수하는 관리 기기만이 성공적으로 연결해 사내 자원에 접근 할 수 있습니다.

Check Point 앱은 Check Point Security Gateway를 거쳐 회사 네트워크로 보안 VPN 연결을 엽니다. 게이트웨이는 MDM 서버의 정책을 조회 하고, VPN 연결이 맺어질 때 MDM 서버는 직원 모바일 기기의 준수 수준을 확인합니다. 게이트웨이는 MDM 결과와 사용자 권한을 종합해, 기기 보안 상태에 따라 접근을 허용하거나 차단 합니다.

이 기능은 Check Point Capsule Connect 와 Capsule Workspace 클라이언트 에서 지원됩니다.

MDM Enforcement 작업 흐름 개요 입니다.

Security Gateway에서 MDM 구성하기

Mobile Access Gateway에서 MDM Enforcement는 구성 파일 로 켭니다. 절차는 이렇습니다.

   vi $FWDIR/conf/mdm.conf
   

     :enabled (1)
     

전역 MDM CE 파라미터

벤더 MDM 파라미터

mdm.conf 파일에는 벤더마다 옵션 블록 이 하나씩 있습니다. 벤더의 API와 PHP 언어를 이해한다면 블록을 더 추가할 수 있습니다("Advanced Vendor Support" 참고). 최신 벤더 정보는 sk98201을 참고하세요.

mdm.conf 파일에서 password 난독화하기

전역 파라미터 password_is_obscured 값이 (1) 이면, $FWDIR/conf/mdm.conf 파일의 모든 password를 난독화 해야 합니다. 절차는 이렇습니다.

   obfuscate_password <password in clear text>
   

출력은 문자열입니다(예: 33542b323a3528343640). 4. 이 출력을 password 파라미터의 값으로 씁니다. 반드시 큰따옴표로 감싸야 합니다.

   :password ("[obfuscated password]")
   

Advanced Vendor Support — 벤더 직접 추가

$FWDIR/conf/mdm.conf 파일에 벤더를 더 추가할 수 있습니다. 단, PHP 프로그래밍 기술과 제3자 MDM 벤더의 클라우드 API에 대한 이해 가 필요합니다.

아래 예시 절차에서는 가상의 MDM 벤더 이름으로 BestMDM 을 씁니다. BestMDM의 API는 자격 증명과 기기 ID가 든 XML 요청을 자사 URL로 보내야 하며, 기기 상태(status)와 사유(reason)가 든 XML 응답을 돌려줍니다.

예시 요청(Request) :

     <username>api_username</username>
     <password>api_password</password>
     <device>device_id</device>
</request>

예시 응답(Response) :

     <status>compliance_status_code</status>
     <reason>reason</reason>
</response>

예시 URL :

https://bestmdm.com/api

새 제3자 벤더 지원을 추가하는 방법입니다.

   vi $CVPNDIR/phpincs/MDMVendors.php
   

   to add another vendor uncomment the following
   

   case "MDM_VENDOR_NAME"
   

주의: - case 단어 위의 /* 문자를 제거합니다. - break 단어 뒤의 */ 문자를 제거합니다. - MDM 벤더 이름을 입력합니다.

예시:

   case "BestMDM":
        BestMDM($mdm_data);
        break;
   

   function BestMDM($mdm_data) {
   // Build the request XML
        $request_xml = new SimpleXMLElement
   ("<request><username/><password/><device/></request>");
   // Fill its fields with data from $mdm_data.
   // Note that "username", "password" and "device_id" always in $mdm_data.
        $request_xml->username = $mdm_data["username"];
        $request_xml->password = $mdm_data["password"];
        $request_xml->device = $mdm_data["device_id"];
   // Make POST request using the supplied class URLRequest
   // (The class URLRequest is defined in the same .php file).
        $url = "https://bestmdm.com/api";
        $conn = new URLRequest(); // open HTTP/HTTPS request session
        $resp_data = $conn->Request( $url, $post_body = $xml->asXML() );
   // Handle possible network error.
        If ($resp_data === FALSE)
   return array("status"=>MDM_ERROR, "reason"=>
        $conn->get_error_message());
   // Now $resp_data is raw string returned by the cloud API. Parse it as XML:
        $resp_xml = new SimpleXMLElement($resp_data);
   // Check the status codes returned by the vendor's API.
        $status = MDM_ERROR;
   switch ($resp_xml->status) {
   case "not_managed":
   return array("status"=>MDM_NOT_MANAGED, "reason"=>"");
   case "compliant":
   return array("status"=>MDM_COMPLIANT, "reason"=>"");
   case "not_compliant":
   return array("status"=>MDM_NOT_COMPLIANT, "reason"=>$resp_xml->reason);
   default:
   return array("status"=>MDM_ERROR, "reason"=>"unknown status");
             } // end switch
        } // end BestMDM compliance protocol handler
   

함수가 반환하는 상태 코드(Status Codes) 의 의미입니다.

        "device_id"=><MAC address of device, or other ID known by the vendor>,
        "username"=><username to access the API of the MDM vendor>,
        "password"=><password to access the API of the MDM vendor>
   )
   

$mdm_data 예시 — mdm.conf 파일의 구성이 $mdm_data 에서 어떻게 표현되는지 보여 줍니다.

   vi $FWDIR/conf/mdm.conf
   

   :BestMDM (
   :username (MyUserName)
   :password (123456)
   )
   

   For example: :active_vendor (BestMDM)
   

MDM 테스트하기

MDM 기능이 올바르게 구성됐는지 확인하는 방법입니다.

Advanced Testing — 기기 없이 테스트하기

기기를 손에 들지 않고도 MDM 구성이 동작하는지 확인할 수 있지만, 전문 지식이 필요 합니다. 테스트 웹 페이지에 로그인해 실제 기기의 WiFi MAC 주소 를 입력하는 방식입니다. 보안을 위해 이 MDM 테스트 페이지는 기본적으로 비활성화 되어 있습니다.

테스트 페이지를 켜는 방법입니다.

   cp -v $CVPNDIR/conf/includes/Login.location.conf{,_BKP}
   

   vi $CVPNDIR/conf/includes/Login.location.conf
   

   To test your integration with the MDM vendor
   

   https://<Host Name of Mobile Access Portal>/sslvpn/Login/MDMProxy
   

    cp -v $CVPNDIR/conf/includes/Login.location.conf{_BKP,}
    

진단 예시(Example Diagnostics) — 테스트가 실패할 때 흔한 원인입니다.