신뢰할 수 있는 기기에 대한 액세스를 활성화한 후 - 온프레미스 및 클라우드의 애플리케이션 및 데이터 소스에 대한 보안 경로 생성 - 이제 "익명" 기기 액세스를 방지하여 데이터 소스를 잠금으로써 시작할 수 있습니다.
익명 기기는 조직에서 인정되지 않는 모든 기기입니다. 여기에는 다음이 포함됩니다:
- 공격자의 노트북
- User Enrolled되지 않은 개인 iPhone
- 배우자의 노트북
- 카페 PC
지금이 더 중요해졌습니다 신뢰할 수 있는 기기로만 액세스를 제한하려면, 하지만 "온프레미스" 경계가 사라진 클라우드 및 원격 작업으로 인해 복잡해집니다. 그럼에도 불구하고 Trusted Access 솔루션 및 아키텍처는 온프레미스 및 클라우드를 포함한 모든 데이터 소스의 잠금을 지원하도록 요구합니다.
온프레미스/데이터 센터 리소스 잠금
많은 조직은 직접 제어하고 관리하는 서버에 상당한 양의 민감한 애플리케이션과 데이터를 보유하고 있습니다. 이러한 서버는 프라이빗 설비 또는 적절히 보호된 데이터 센터에 설치됩니다.
다행히 이러한 애플리케이션은 이미 방화벽이 있어 개방 내부 액세스에서 클로킹됩니다. 그러나 확인해야 할 몇 가지 사항이 있습니다:
- 매핑된 공용 IP (ISP 발급 CIDR 범위 내)를 대상 서버에서 제거합니다. 서버는 프라이빗 IP 주소를 통해서만 도달해야 합니다.
- 공용 IP 주소를 서버의 내부 IP 주소로 매핑하는 1 대 1 NAT 또는 방화벽 핀홀 예외를 제거합니다. 이는 HTTP 및 RDP와 같은 위험한 프로토콜에 특히 중요합니다.
- 애플리케이션이 특히 민감한 경우 IPSec 인터커넥트의 암호화 도메인 설정에 정의된 Jamf Subnet에서만 애플리케이션 인바운드 연결을 허용하도록 서버 또는 LAN의 네트워크 ACL (액세스 제어 목록)을 구성합니다.
신뢰할 수 있는 사용자와 해당 기기는 Custom IPSec Interconnect Gateway를 통해 이러한 리소스에 도달하며, 기기에 배포 및 활성화된 Jamf Trust와 함께 원활하게 도달할 수 있습니다.
Infrastructure as a Service (IaaS) 리소스 잠금
Infrastructure as a Service는 물리 인프라를 관리할 필요 없이 애플리케이션을 실행하고 데이터를 저장할 수 있도록 하는 제3자 공급업체 제공 클라우드 기반 서비스로 정의됩니다. 시장에서 가장 일반적인 IaaS 플랫폼은 Amazon Web Services, Google Cloud Platform 및 Microsoft Azure입니다.
이러한 환경의 리소스에 대한 액세스 제한은 실제로 온프레미스/데이터 센터 리소스와 매우 유사합니다. 리소스는 일반적으로 IaaS 공급자 내의 프라이빗 가상 네트워크에서 구성됩니다. 그러나 큰 차이점은 애플리케이션과 데이터 리소스가 공개적으로 사용 가능하게 되는 것이 훨씬 더 일반적입니다. 의도적이든 우발적이든 (해야 하기가 쉽기 때문) 이 과도한 개방 액세스는 최근 몇 년 동안 많은 중요한 해킹의 근원이었습니다.
신뢰할 수 있는 사용자 및 기기는 다음 인터커넥트 옵션 중 하나를 사용하여 이러한 리소스에 도달할 수 있습니다:
- AWS 인터커넥트
- Azure 인터커넥트
- Custom IPSec Interconnect Gateway
- Jamf Internet Cloud Gateway에서만 IaaS 액세스 정책을 통해 인바운드 액세스를 제한하고 다른 모든 연결을 차단합니다.
- macOS용 AWS Verified Access를 구성하여 관리 및 준수 기기에 대한 액세스 제한.
Software as a Service (SaaS) 리소스 잠금
Software as a Service는 구매했지만 작동의 소유권이 없는 애플리케이션으로 정의됩니다. 일반적인 비즈니스 SaaS 서비스에는 Microsoft 365, Salesforce, Slack, Box 및 Zoom이 포함됩니다. 조직이 최소 하나의 SaaS 앱을 가지고 있을 가능성이 있으며 일부 민감한 회사 데이터를 포함하고 있습니다!
그러나 SaaS 앱의 기본 인프라 (네트워크 연결 포함)에 대한 기본 제어가 없으면 인정된 사용자와 기기를 식별하기 위해 사용될 수 있는 (또는 그렇지 않을) 액세스 제어를 제공하기 위해 SaaS 공급자의 자비로 이루어집니다.
일반적으로 SaaS 앱에 대한 액세스를 잠그는 데 두 가지 기술이 사용 가능합니다: 소스 IP 또는 신원 공급자 (IdP)를 통해.
소스 IP 주소 사용
일부 SaaS 공급자는 개별 고객이 특정 고객 테넌트에 로그인할 수 있는 소스 IP 주소 범위를 정의할 수 있게 합니다. 상대적으로 드물지만 소스 IP 잠금은 Jamf Private Access 인프라를 통해 연결하는 기기의 액세스만 허용하는 신뢰할 수 있는 방법입니다.
Jamf의 공유 글로벌 IP 주소 또는 Custom IPSec Interconnect Gateway의 다른 쪽에 있는 공용 IP를 사용할 수 있습니다.
이를 강력하게 보여주는 예는 Microsoft Exchange 연결을 Private Access 사용 기기로만 제한하는 액세스 클라이언트 액세스 규칙을 사용하는 것입니다.
신원 공급자 사용
대부분의 SaaS 공급자는 Single Sign On을 지원합니다. 이는 별도의 자격증명 세트에 의존하는 대신 조직의 신원 공급자 (예: Okta, Azure AD)를 사용하여 해당 애플리케이션에 액세스를 허용하거나 거부합니다. 이는 사용자 신원에 좋지만 SaaS 공급자는 거의 기기 액세스 제어를 제공하지 않습니다.
다행히 신원 공급자 는 인정된 기기를 승인되지 않은 기기와 구별하는 데 사용할 수 있는 기기 수준 인식을 지원합니다.
Jamf 소스 IP를 통해
시장의 세 주요 IdP는 sign-on 액세스 정책을 정의하여 주어진 SaaS 앱에 로그인할 수 있는 기준으로 소스 IP 주소를 고려하도록 지원합니다.
이 기준을 사용하여 Jamf의 클라우드 IP 주소를 사용하여 들어오는 로그인이 Private Access 배포 및 활성화된 기기에서 발생했는지 여부를 식별할 수 있습니다. 권한이 없는 기기는 Jamf Security Cloud에 속하는 소스 IP를 제시하지 않으므로 IdP의 액세스 정책에 의해 차단됩니다.
IdP에 대해 이를 구성하는 방법에 대한 세부사항은 다음 가이드를 참조하세요:
여기에 있는 BYOD 데모 비디오에서 이러한 환경이 어떤 모습인지 볼 수 있습니다.
IdP Endpoint 앱/에이전트를 통해
일부 IdP는 로그인 프로세스의 일부로 기기 신원 및 인증을 전달하는 데 사용될 수 있는 엔드포인트 앱/에이전트를 제공합니다. 이 방법이 소스 IP를 사용하는 것보다 낫지만 추가 배포 및 활성화 고려사항과 복잡성이 필요합니다.
- Okta: 관리 기기 및 인증 정책 추가 (특히 "기기 관리"를 기준으로 사용)를 참조하세요.
- 참고: Okta Identity Engine (OIE) 필요
- Microsoft Azure AD: 기기 기반 조건부 액세스 정책을 Jamf Pro 및 Microsoft 조건부 액세스 통합과 함께 사용하세요.