모든 연방 기관에 엔터프라이즈 애플리케이션 전략이 필요한 이유와 이를 구축하는 방법

미국 연방 기관의 IT 임원은 낭비를 줄이고 사이버 공격으로 인한 손실을 최소화하는 동시에 더 많은 가치를 제공하기 위해 어려운 경계선을 걸어야 합니다. 한편, IT 리더는 더 큰 효율성을 실현하고, 더 많은 가치를 제공하며, 납세자의 돈을 절감하기 위해 최신 기술을 도입해야 합니다. 반면에, 그들은 완화하기 위해 상당한 자원이 필요한 진화하고 확대되는 위협 환경에 직면해 있습니다. 간단히 말해, 모든 이니셔티브와 모든 결정에서 혁신하고 보호해야 합니다. 이처럼 상반되는 것처럼 보이는 목표를 달성하기 위해 연방 IT 리더는 조직의 사명에 맞는 엔터프라이즈 애플리케이션 전략을 개발해야 합니다.

F5 2019 애플리케이션 서비스 현황 보고서에 따르면, 설문 조사에 참여한 응답자의 65%가 자신의 조직이 디지털 혁신을 겪고 있다고 답했습니다. 디지털 혁신은 조직이 기술을 사용하여 성과와 사용자 생산성을 크게 개선할 수 있는 새로운 방법입니다.

간단히 말해, 애플리케이션이 비즈니스나 사명 그 자체가 되고 있습니다.

이러한 급진적인 변화를 활용하기 위해 조직에서는 다음과 같은 새로운 비즈니스 및 IT 운영 모델을 추구하면서 광범위한 변화를 추진하고 있습니다.

• 클라우드 기반 이메일 및 생산성 도구와 같은 SaaS 서비스에 의존
• 관리를 간소화하고 비용을 절감하기 위해 사용자 정의 애플리케이션을 컨테이너화합니다.
• 클라우드 보안 서비스를 사용하여 공격을 신속하게 파악하고 조직 규칙에 따라 정책을 적용합니다.

다양한 유형의 기기에 애플리케이션이 제공되고 있습니다. 애플리케이션에 액세스하는 사용자는 기존의 기업 환경에 거주하지 않습니다. 즉, 모바일이거나 재택근무자입니다. CRM, ERP 등 비즈니스에 중요한 기능을 제공하려면 기존 기업 네트워크 외부에서도 액세스할 수 있어야 합니다.

2018년 F5 Labs 애플리케이션 보호 보고서에 따르면, 평균적으로 공공 부문 조직은 680개의 애플리케이션을 사용하고 있으며, 그 중 32%가 미션 크리티컬로 간주되는 것으로 나타났습니다.

애플리케이션의 엄청난 성장에 더해, 기업들은 이러한 애플리케이션을 새로운 아키텍처와 서비스에 배포하고 있습니다. 2019년 애플리케이션 서비스 현황 조사에 따르면, 설문 조사에 참여한 조직의 14%가 컨테이너를 기본 애플리케이션 워크로드 격리 방법으로 삼았으며, 응답자의 87%가 멀티 클라우드 아키텍처를 채택하고 있습니다. 관리예산국(OMB) 자체도 "클라우드 스마트 전략"을 옹호하고 있습니다.¹ 안전하고 보안이 강화된 클라우드 네트워크로 이전하세요.

정부와 상업 기관만이 기술을 사용하여 마찰을 줄이고, 새로운 서비스를 제공하고, 가치를 높이는 것은 아닙니다. 사이버 범죄자, 무장 단체, 국가 차원의 위협 행위자들 역시 엄청난 속도로 사이버 공격 역량을 혁신하고 있습니다. 네트워크와 인프라를 보호하는 능력이 향상되면서 사이버 공격자들은 더 쉬운 타깃을 노리고 있습니다.

소프트 타겟은 인력이나 기밀 정보가 저장되어 있는 고가 자산에 침투하는 데 사용됩니다. F5 랩의 조사에 따르면, 모든 사이버 공격자의 86%가 애플리케이션을 직접 공격하거나 주로 피싱을 통해 사용자 신원을 훔칩니다.²

공격자들은 간접 공격이 더 쉬운 경우가 있다는 것을 깨닫고 있습니다. 한 가지 방법은 IoT 기기와 같이 덜 중요한 애플리케이션을 대상으로 접근하고 해당 애플리케이션의 액세스 수준을 높이는 것입니다. 범죄자들이 로비 수족관 온도계를 통해 미국 카지노를 해킹하여 고액 플레이어 데이터베이스에 접근하는 발판으로 사용한 경우가 바로 그렇습니다.³ 마찬가지로 2013년 Target의 파괴적인 데이터 유출 사고는 Target의 HVAC 공급업체를 악용하여 시작되었지만 POS 시스템 유출과 4,000만 장의 신용카드 손실로 끝났습니다.⁴

관리되지 않는 오픈 소스 및 기타 타사 구성 요소와 서비스도 위험을 초래할 수 있습니다. Sonatype의 2018년 소프트웨어 공급망 현황에 따르면 오픈소스 구성 요소 다운로드 8개 중 1개에는 알려진 보안 취약점이 포함되어 있습니다.⁵ 공공 부문을 포함한 여러 조직에서는 오픈 소스를 활용하여 개발 및 제공 속도를 높입니다. 그러나 동일한 조직이 보안 검사 및 검토 프로세스에 오픈 소스 구성 요소를 포함시키는 데 실패하는 경우가 많습니다. 이러한 구성요소는 애플리케이션 포트폴리오의 일부가 되므로 사용자 정의 코드와 동일한 주의 깊게 처리해야 합니다. 여기에는 서버 측(예: NPM 패키지, 라이브러리)과 클라이언트 측의 구성 요소가 모두 포함됩니다.

이제 애플리케이션이 조직의 목표를 달성하는 데 더욱 중요한 역할을 하게 되면서 이러한 앱의 성장은 대부분 조직이 운영을 확장하는 능력을 앞지르고 있습니다. 경계에 보안을 두는 기존 모델은 확장성이 없고 위협을 예방하는 데 효과가 제한적입니다. 일단 소프트 타겟이 침해당하면 고가의 자산이 위험에 처하게 됩니다. 새로운 아키텍처와 배포 모델은 기존 보안 조치에 더욱 큰 어려움을 초래합니다. 앱은 분산된 위치에 배치되고, 성능을 개선하기 위해 멀티 클라우드 애플리케이션 서비스를 사용하고 있습니다. 그 사이, 애플리케이션과 관련된 위협 표면 영역이 기하급수적으로 확대되고 있습니다.

성능을 유지하면서 보안을 제공하려면 애플리케이션과 소프트 대상에 대한 지속적인 모니터링이 중요합니다. 지능형 클라우드 보안을 통합하면 애플리케이션과 함께 작동하여 위협을 신속하게 완화하고 중요한 데이터를 보호할 수 있습니다. 소규모 데이터 유형을 클라우드로 전송하여 클라우드 내에 저장된 수백만 개의 아티팩트와 데이터를 비교하여 잠재적 위협을 식별할 수 있습니다. 이는 클라이언트가 봇인지 실제 사용자인지 판별하는 데 사용할 수 있습니다.

사기 감소 서비스는 악의적인 행위자와 상호 작용하는 애플리케이션과 함께 작동하여 더 많은 데이터 유형을 얻고 대규모 사기를 방지할 수 있습니다. 전체 사기 프로필은 조직의 지속적인 모니터링 시스템에 전달되어 조치를 취하고, 공격 확산을 방지하고, 손상된 시스템의 위치를 확인하고, 감염된 컴퓨터에서 위협을 제거하기 위한 단계를 제공할 수 있습니다. 분석가는 추가 분석을 위해 운영 부서에 정보를 제공할 수 있습니다.

상황이 충분히 복잡하지 않은 듯, 연방 기관은 더 큰 유연성을 활용하고, 더 높은 가용성을 확보하고, 공급업체 잠금을 줄이고, 어떤 경우에는 더 낮은 비용을 활용하기 위해 멀티 클라우드와 SaaS 배포로 전환하고 있습니다. 난제는 다음과 같습니다. 예산 할당을 초과하지 않으면서 하이브리드, 멀티 클라우드, SaaS 아키텍처에서 표준화되고 안전하며 원활한 애플리케이션 경험을 제공하려면 어떻게 해야 할까요?

기관에서는 신뢰할 수 있는 인터넷 연결 지점에서 경계 솔루션을 사용하여 SaaS 및 멀티 클라우드 환경에 대한 연결을 보호할 수 있습니다. 기관의 연결 지점이 제한되어 있어 성능 문제가 발생할 수 있습니다. 대중에게 공개되는 애플리케이션은 보안을 위해 이러한 지점을 통과해야 하며 이로 인해 지연이 발생합니다. 보안을 위해 트래픽을 "트롬본"해야 하기 때문에 확장 가능하고 성능이 뛰어난 애플리케이션을 갖는 이점이 사라집니다.

경계 솔루션도 정적 서명에 의존합니다. 새로운 위협이 개발되어 보안 클라우드 공급자 내에서 프로파일링이 이루어진 경우, 해당 정보는 공격을 방지하기 위해 경계 시스템으로 전달되지 않습니다. 서명 업데이트는 하루 또는 일주일 내에 이루어질 수 있습니다. 경계 보안 시스템 내에서 서명이 최종적으로 개발되어 업데이트되면 고가의 자산이 손상될 수 있습니다.

멀티 클라우드와 SaaS 애플리케이션 서비스를 표준화하면 애플리케이션을 보호, 관리, 최적화하는 데 필요한 솔루션을 구축할 수 있으며, 이를 통해 멀티 클라우드 아키텍처와 함께 발생하는 운영상의 복잡성을 줄일 수 있습니다.

예를 들어, API의 코드 기반 호출이나 이벤트 기반 시스템과 같이 엔터프라이즈 애플리케이션 수준에서 작동하는 서비스는 공급업체별 메시지 대기열 서비스를 사용해야 하는 플랫폼별 서비스보다 관리하기 쉽고 보유하는 것이 더 강력합니다. 모든 애플리케이션에서 한 가지 기능 세트를 활성화하면 운영 오버헤드가 줄어듭니다. 가능한 한 많은 애플리케이션 서비스에 표준 플랫폼을 채택함으로써 조직은 더 많은 자동화를 활용하고 더 많은 코드를 재사용하여 일관되고 예측 가능하며 반복 가능한 운영 프로세스를 실현할 수 있습니다.

클라우드에서 탄생한 많은 조직이 IT 부서조차 없는 시대에 기존 IT 아키텍처와 운영 프로세스는 애플리케이션 개발자와 DevOps 팀의 기대에 크게 못 미칩니다. 애플리케이션을 더 빠르게 출시하려는 욕구로 인해 기존의 네트워킹 및 보안 팀은 물론 관련 보안 및 운영 프로세스를 우회하는 경우가 많습니다. 실제로, 기업 애플리케이션 포트폴리오를 보호하는 일은 기술뿐만 아니라 사람과 프로세스와도 많은 관련이 있습니다.

이러한 멀티 클라우드 확산에서 성능을 관리하고, 더 중요하게는 위험을 관리하기 위해 기업은 필사적으로 솔루션을 찾고 있습니다. 애플리케이션이 어디에 있든 솔루션은 일관된 정책의 배포를 지원하고, 위협을 관리하고, 가시성을 제공하며, 앱 상태와 성능을 모니터링할 수 있어야 합니다. 혁신과 애플리케이션 개발 및 DevOps 팀의 민첩성이 방해를 받는다면, 적합하지 않은 솔루션은 디지털 혁신의 이점을 쉽게 감소시킬 수 있습니다.

애플리케이션의 가치와 위험 프로필이 증가함에 따라 모든 연방 기관은 엔터프라이즈 포트폴리오의 애플리케이션을 구축/획득, 배포, 관리 및 보호하는 방법을 다루는 엔터프라이즈 애플리케이션 전략을 개발해야 합니다.

요약: 이 기회를 활용하여 귀하의 연방 기관의 사명과 목표에 부합하는 엔터프라이즈 애플리케이션 전략을 수립하세요.

디지털 혁신의 요점은 다루기 힘들고 수동적인 프로세스를 효율적이고 데이터가 풍부한 애플리케이션으로 대체하는 것입니다. 따라서 엔터프라이즈 애플리케이션 전략의 포괄적인 목표는 임무 수행과 관련하여 조직의 디지털 역량을 직접적으로 향상, 가속화하고 보호하는 것이어야 합니다. 이 목표에 부합하지 않는 모든 애플리케이션이나 관련 애플리케이션 서비스는 우선 순위에서 제외해야 합니다. 높은 우선순위의 애플리케이션에는 추가적인 리소스와 보안이 제공되어야 하며, 우선순위가 낮은 자산은 공유 리소스를 사용할 수 있습니다.

이러한 정렬은 또한 현상 유지를 고려하는 것을 의미하는데, 여기에는 현재의 기업 데이터 전략, 규정 준수 요구 사항 및 조직의 전반적인 위험 프로필을 주의 깊게 살펴보는 것이 포함됩니다.

많은 경우, 이러한 다양한 소스에서 발생하는 제약과 앱 개발팀의 민첩성에 미치는 영향은 제대로 이해되지 않는 경우가 많습니다. 기업 애플리케이션 전략에서는 혁신, 민첩성, 위험이라는 종종 경쟁하는 세력 사이에서 기관이 이루고자 하는 균형을 명확히 해야 합니다.

요약: 현대화를 시작하기 전에 완전한 애플리케이션 인벤토리를 구축해야 합니다.

기업 애플리케이션 전략과 관련해 대부분의 팀은 처음부터 다시 시작할 만큼 운이 좋지 않습니다. IT 산업에 종사하는 거의 대부분의 사람들은 수십 년간 서로 다른 시스템을 혼합하여 기능을 유지하도록 만든 기술 아키텍처를 물려받았습니다. 이 문제는 상업 부문에 비해 미국 연방 정부 내에서 특히 심각할 수 있습니다. 이러한 불일치하는 기술 요소를 원하는 대상 상태로 깔끔하게 이전하는 것은 거의 쉽지 않습니다. 그러므로 더 많은 발견과 분석이 이루어져야 합니다.

너무 단순하게 들릴지 몰라도, 무언가를 적절히 보호하려면 먼저 그것이 존재한다는 사실을 알아야 하고, 그런 다음 그 상태대로 정확하게 모니터링할 수 있어야 합니다. 그런데도 몇 가지 예외를 빼고 대부분 기업은 포트폴리오에 있는 애플리케이션의 수를 자신 있게 보고할 수 없으며, 더구나 해당 애플리케이션이 건전하고 안전한지 여부도 알 수 없습니다. F5 Labs 2018 애플리케이션 보호 보고서에 따르면 IT 보안 리더의 62%가 조직의 모든 애플리케이션에 대해 아는 것에 대해 자신감이 낮거나 전혀 없다고 밝혔습니다.

애플리케이션 인벤토리는 모든 애플리케이션 전략의 가장 기초적인 요소입니다. 이는 내부적으로, 측면적으로(예: 다른 정부 기관에), 또는 외부적으로(예: 대중에) 제공되는 모든 애플리케이션의 카탈로그로, 여기에는 다음이 포함됩니다.

• 애플리케이션 또는 디지털 서비스가 수행하는 기능에 대한 설명
• 애플리케이션의 출처(예: 맞춤 개발, 패키지 소프트웨어 또는 타사 서비스)
• 애플리케이션이 액세스하거나 조작해야 하는 주요 데이터 요소
• 애플리케이션이 통신하는 다른 서비스
• 애플리케이션의 일부인 오픈 소스 및 기타 타사 구성 요소
• 신청서에 대한 책임이 있는 개인 또는 그룹

처음으로 애플리케이션 인벤토리를 구축하는 것은 종종 힘들고 시간이 많이 걸리는 작업입니다. 악성 애플리케이션을 쉽게 찾아내는 한 가지 방법은 애플리케이션 인벤토리를 허용 목록으로 만드는 것입니다. 허용 목록에 없는 애플리케이션은 엔터프라이즈 리소스(예: 네트워크)에 액세스할 수 없습니다. 조직 외부의 애플리케이션을 추적하려면 CASB(클라우드 액세스 보안 브로커)와 같은 도구가 매우 유용할 수 있습니다. CASB는 사용자와 인터넷 사이에 위치하여 모든 애플리케이션 활동을 모니터링하고 보고합니다. 직원들이 가장 많이 사용하는 애플리케이션(그리고 직원들이 애플리케이션에 액세스하는 방법)을 알려줄 수 있을 뿐만 아니라, 섀도 IT 애플리케이션 사용에 대한 통찰력도 제공할 수 있습니다.

DevOps 아키텍처 모델을 채택하고 여기에 애플리케이션을 통합하면 향후 인벤토리 프로세스를 간소화할 수 있습니다. 애플리케이션의 우선순위가 결정되고 이를 멀티 클라우드 또는 SaaS 환경에 배치하면 개발자는 오픈 소스 도구(예: Ansible, GitHub)를 사용하여 배포를 패키징할 수 있습니다. 그런 다음 배포는 보안 서비스, 패치 관리, 코드를 포함한 도구를 통해 관리됩니다. 재고 정보는 중앙에서 관리되며 신속하게 제공될 수 있습니다. 따라서 해당 애플리케이션은 클라우드나 SaaS 환경에 존재할 수 있지만 여전히 조직에서 식별될 수 있습니다.

애플리케이션 인벤토리의 정확성을 보장하는 데 투자한 모든 순간은 FedRAMP 시스템 경계를 신속하게 정의하는 능력에 직접적으로 긍정적인 영향을 미칩니다. 또한 인증 기관에서 요청할 경우 애플리케이션 인프라에 대한 책임 당사자(또는 애플리케이션의 개별 구성 요소)를 빠르고 정확하게 찾을 수 있는 훨씬 더 정확한 방법을 제공합니다.

마지막으로, FedRAMP 활동을 위해서는 이를 지속적으로 실시해야 하며, 1년에 한 번 이상 실시해야 합니다. 이는 어떤 애플리케이션과 데이터 저장소가 사용 중인지 계속 살펴보고, 사용자가 무엇을 해야 하는지 모니터링하고, 개발 환경이 어떻게 진화하고 있는지 평가하는 지속적인 프로세스입니다.

요약: 각 애플리케이션의 개별 위험 수준을 살펴보고 보안 조치를 결정할 때 해당 위험 수준을 모든 해당 규정 준수 고려 사항과 결합합니다.

사이버 위험은 미국 정부의 IT 리더들에게 심각하고 점차 더 큰 우려 사항입니다. 이를 방지하려면 먼저 각 애플리케이션에 대한 사이버 위험을 평가해야 합니다.

인벤토리의 각 애플리케이션은 4가지 주요 사이버 위험 유형에 대해 검사해야 합니다.

1. 민감한 내부 정보(예: 군사 비밀)의 유출
2. 민감한 고객/사용자 정보(예: 인사 기록, 세무 내역) 유출
3. 데이터 또는 애플리케이션 변조
4. 데이터 또는 애플리케이션에 대한 서비스 거부

사이버 위험의 경우 디지털 서비스의 중요성은 위 범주에 따른 사이버 공격으로 인해 해당 서비스에 미치는 재정적 또는 평판적 영향을 고려하여 측정해야 합니다. 각 조직은 특정 서비스에 대해 다른 서비스보다 잠재적 손실 수준을 다르게 책정하므로 각 조직은 정의된 사명에 따라 자체적으로 추산을 해야 합니다. 예를 들어 FISMA에서는 임무나 사업 사례에 대한 기관 수준의 위험을 파악하도록 요구합니다. 하지만 임무의 준수 기준이 불가피하게 심화될 때를 대비하기 위해 애플리케이션 수준에서도 위험을 조사하는 것이 실용적인 경우가 많습니다.

때로는 조직적 위험 계산에 해당 규칙, 지침 및 계약을 준수하지 않을 경우의 위험이 포함되기도 합니다. 연방 기관은 규정과 표준을 엄격히 준수해야 하며, 애플리케이션과 디지털 서비스를 평가할 때 이러한 사항을 모두 고려해야 합니다. 사이버 위험을 평가하기 위한 애플리케이션 연결 모델을 구축하면 관리 가능하고 적절히 세분화된 서비스 그룹으로 경계를 좁힐 수 있으므로 FedRAMP 규정 준수를 위한 CDM/ConMon 요구 사항을 충족하는 프로세스가 용이해집니다.

SaaS 서비스를 사용하면 조직의 규정 준수 문제를 줄이는 데 도움이 될 수 있습니다. 애플리케이션 위험과 규정 준수 문제는 SaaS 제공자의 책임입니다. 이를 통해 조직은 맞춤형 애플리케이션에 집중할 수 있습니다.

사용자 계정, 재무 데이터 및 개인 정보를 보호하기 위해 애플리케이션 내에 클라우드 보안 서비스를 통합하는 것을 고려해보세요. 클라우드 보안 서비스에는 수백만 개의 데이터 포인트가 있으며, 애플리케이션은 이를 사용하여 클라이언트가 악의적인지 아니면 실제 사용자인지 판단할 수 있습니다. 데이터 포인트가 지속적으로 업데이트되므로 새로운 위협을 식별할 수 있습니다. 규칙은 실시간으로 애플리케이션에 적용할 수 있으며 기존 기업 보안 전략과 함께 작동할 수 있습니다.

요약: 조직에 필요한 애플리케이션 서비스(즉, 애플리케이션을 백그라운드에서 실행하는 솔루션)가 무엇인지 파악하세요.

애플리케이션은 독립적으로 실행되는 경우가 거의 없으므로 애플리케이션 인벤토리와 함께 앱을 실행하는 애플리케이션 서비스를 관리하고 추적해야 합니다. 애플리케이션 서비스는 애플리케이션 빌더를 위한 패키지 솔루션으로, 애플리케이션의 속도, 이동성, 보안 및 운용성을 개선합니다. 앱 서비스는 애플리케이션 작업 부하에 여러 가지 중요한 이점을 제공합니다.

• 속도: 애플리케이션 워크로드의 성능과 신속한 제공 능력.
• 이동성: 애플리케이션 워크로드를 하나의 물리적 또는 논리적 호스팅 사이트에서 다른 물리적 또는 논리적 호스팅 사이트로 쉽게 이동하는 것입니다.
• 보안: 애플리케이션 워크로드와 관련 데이터를 보호합니다.
• 조작성: 애플리케이션 워크로드가 쉽게 배포되고, 쉽게 실행되고, 장애가 발생해도 쉽게 문제를 해결할 수 있다는 확신입니다.

종속된 애플리케이션 서비스를 찾는 좋은 방법은 해당 환경에 대한 FISMA 또는 FedRAMP 시스템 보안 계획의 제어 섹션을 검토하는 것입니다. 이는 보안 중심 애플리케이션 서비스와 이에 종속된 다른 서비스의 존재를 나타냅니다. 

모든 애플리케이션은 애플리케이션 서비스로부터 이점을 얻을 수 있지만, 모든 애플리케이션에 동일한 애플리케이션 서비스가 필요한 것은 아닙니다.

일반적인 응용 프로그램 서비스는 다음과 같습니다.

• 부하 분산
• DNS 전달
• 글로벌 서버 로드 밸런싱
• 웹 애플리케이션 방화벽
• DDoS 방지/보호
• 애플리케이션 모니터링 및 분석
• ID 및 액세스 관리
• 애플리케이션 인증
• API 게이트웨이
• 컨테이너 입출구 제어
• SSL 암호화

모든 애플리케이션 서비스에는 직접적으로(서비스 자체 측면에서) 또는 간접적으로(운영 유지 관리 측면에서) 어느 정도 비용이 발생합니다. 우선순위가 낮은 애플리케이션은 공유 기능을 사용하여 비용을 절감할 수 있습니다. 공유된 기능은 보안을 제공하고 성능을 유지합니다. 높은 가치의 자산은 조직의 생산성에 매우 중요하기 때문에 더 많은 자원이 필요합니다.

많은 앱 서비스가 좁은 범주의 애플리케이션을 지원하도록 특별히 설계되었다는 점에 주목할 가치가 있습니다. 예를 들어, IoT 앱을 지원하도록 설계된 애플리케이션에만 IoT 게이트웨이가 필요합니다. 기존 아키텍처에서 제공되는 애플리케이션은 컨테이너화된 환경을 타겟으로 하는 앱 서비스가 필요하지 않으므로 인그레스 제어 및 서비스 메시 애플리케이션 서비스가 적용되지 않을 수 있습니다.

어떤 경우에는 규정 준수를 보장하거나 위험을 줄이기 위해 새로운 애플리케이션 서비스를 인수해야 할 수도 있습니다. 기술적으로는 규정 준수 기준을 충족할 수 있지만, 항상 최소한의 기준 통제를 선택하려는 유혹을 이겨내고 사이버 위험을 처리하는 능력을 향상시키는 애플리케이션 서비스를 선택해야 합니다.

요약: 유형, 우선순위, 요구 사항을 기준으로 애플리케이션을 논리적으로 그룹화합니다.

애플리케이션 인벤토리가 완료되면 다음 단계는 다양한 관리 및 애플리케이션 서비스 접근 방식(예: 중요 데이터에 대한 액세스, 더 많은 위협에 노출됨)이 필요한 특성에 따라 애플리케이션을 논리적 범주로 그룹화하는 것입니다.

분류가 완료되면, 엔터프라이즈 애플리케이션 정책은 애플리케이션 자체의 중요도와 엔터프라이즈 분류에 따라 다양한 애플리케이션 유형에 적용될 성능, 보안 및 규정 준수 프로필을 지정해야 합니다.

4가지 기본 단계부터 시작하는 것이 좋습니다.

애플리케이션이 직면한 위협은 호스팅되는 환경에 따라 다르므로, 이러한 분류는 배포 환경(예: 온프레미스, 퍼블릭 클라우드)을 기준으로 더욱 확장하여 구별할 수 있습니다.

이런 방식으로 목표의 우선순위를 정하면 배포할 애플리케이션을 적절한 FISMA/FedRAMP 수준에 맞춰 쉽게 사전 분류하는 데도 도움이 됩니다. 여기서 임무 목표에 대한 구조를 개발하는 데 약간의 시간을 투자하면 나중에 감사원과 대화하는 데 소요되는 시간을 크게 줄일 수 있습니다.

어떤 조직도 허용 가능한 기간 내에 원하는 모든 것을 할 수 있는 충분한 자원을 갖추고 있지 않습니다. 애플리케이션의 우선순위를 정함으로써 애플리케이션 서비스로 강화해야 할 앱, 현대화 또는 교체해야 할 앱, 노력할 가치가 없는 앱을 구분하는 분류 접근 방식을 취할 수 있습니다. 후자 범주에 속하는 앱의 경우 네트워크에서 분리되어 있는지 확인하고 무해한 IoT 온도 조절 장치가 전체 네트워크 침해로 이어지는 상황을 피하십시오. 이 프로세스에는 새로운 가치 흐름을 열어줄 수 있는 새로운 애플리케이션을 검토하는 것도 포함되므로 내부적으로 개발하거나 타사에서 조달해야 합니다.

요약: 배포 및 소비 매개변수를 개발합니다.

모든 IT 전략의 기본은 언제나 배포와 운영 관리였으며, 최신 엔터프라이즈 애플리케이션 전략에는 몇 가지 새로운 측면(예: 최종 사용자 경험의 중요성)이 추가되었습니다. 여기에는 다음 사항이 포함됩니다.

• 어떤 배포 아키텍처가 지원되나요(예: 하이브리드 클라우드, 멀티 클라우드)
• 각 애플리케이션 범주에 대한 배포 모델 옵션
• 어떤 퍼블릭 클라우드가 애플리케이션의 액세스 포인트 역할을 할 수 있나요?
• 퍼블릭 클라우드 네이티브 서비스를 타사 서비스에 비해 얼마나 활용할 수 있는가

다양한 애플리케이션에는 배포 및 소비 모델 측면에서 각기 다른 요구 사항이 있습니다. 애플리케이션 전략을 개발하는 이 단계에서는 다양한 배포 옵션을 명확하게 이해해야 합니다. 각 옵션에는 서로 다른 소비 모델, 비용 영향, 규정 준수/인증 프로필이 있을 수 있습니다.

배포 모델을 선택할 때는 결정에 활용할 수 있는 가용한 기술과 인재를 파악하는 것도 신중한 고려사항입니다. 예를 들어, 사내 인력이 부족하고 계약 기반 기술에 대한 접근성이 부족한 상황에서 AWS에 배포하기로 선택하면 속도가 느려지고 위험이 발생할 수 있습니다.

귀하의 배치 및 관리 메커니즘 자체가 FISMA 또는 FedRAMP ATO/P-ATO에 따라 승인 대상이 될 수 있음을 잊지 마세요. 귀하의 기관이 임무에 대한 표준으로 사용하는 것을 따르세요.

요약: 기업 애플리케이션 전략의 각 요소에 대한 명확한 책임 범위를 확립하세요.

목표와 우선순위를 명확히 하는 것 외에도 엔터프라이즈 애플리케이션 전략에는 역할과 책임에 대한 요소도 포함되어야 합니다.

알아야 할 사항:

• 애플리케이션 포트폴리오의 최적화 및 보안(예: 기술 선택, 애플리케이션 배치, 사용자 액세스 관리)과 관련된 의사 결정 권한은 누구에게 있습니까?
• 각 애플리케이션에 대한 권한 있는 사용자 액세스 권한은 누구에게 있습니까?
• 다양한 환경에서 각 애플리케이션의 배포, 운영 및 유지 관리를 담당하는 사람은 누구입니까?
• 엔터프라이즈 애플리케이션 정책을 준수하는 책임은 누구에게 있습니까?
• 엔터프라이즈 애플리케이션 전략 목표 준수 여부를 모니터링할 사람은 누구입니까? 그러면 누구에게 측정 자료를 보고해야 할까?
• 오픈 소스 및 타사 구성 요소/서비스 공급자를 포함한 공급업체의 규정 준수 여부를 모니터링할 사람은 누구입니까?
• 애플리케이션과 서비스가 지속적으로 변경되고 추가/제거됨에 따라 모든 애플리케이션과 애플리케이션 서비스가 설명되도록 보장할 사람은 누구입니까?

이러한 책임은 개인이나 여러 부서로 구성된 위원회, 심지어 전체 부서에 맡겨질 수 있습니다. 그럼에도 불구하고, 이는 명확하게 설명되어야 합니다. 실제로 규정 준수 체계에서 요구하는 것보다 더 많은 정의가 필요할 수도 있습니다.

더욱 발전된 조직에서는 개발 프로세스 초기, 애플리케이션을 시작할 때 이러한 책임을 할당하기 위해 운영 프로세스와 자동화를 도입할 것입니다. 수백 개 또는 수천 개의 애플리케이션이 중요한 기능을 지원하는 멀티 클라우드 환경에서 애플리케이션 전략과 해당 정책은 명확한 책임 범위를 확립해야 합니다.

기업 애플리케이션 전략이 개발되면, 그 목적에 맞게 실행해야 합니다. 시행 메커니즘에는 프로세스 자동화에 내장된 "하드" 가드레일(예: 사용자 액세스 제어, 체크인 시 코드 취약성 검사)과 직원 교육 및 역량 또는 인식 구축과 같은 "소프트" 조치가 포함되어야 합니다.

액세스 제어 정책은 엔터프라이즈 애플리케이션 전략에 정의된 운영적 역할과 책임을 지원해야 하며 온프레미스와 클라우드의 모든 애플리케이션으로 확장되어야 합니다. 애플리케이션에 대한 관리자 권한 또는 루트 권한을 갖고 있는 경우 정교한 APT의 표적이 될 수 있으므로, 권한이 있는 사용자 접근에 특별한 주의를 기울여야 합니다.

권한이 있는 사용자에게 권장되는 특별 조치는 다음과 같습니다.

• 권한이 있는 사용자는 항상 별도의 그룹에 속해야 합니다. 모든 사용자 또는 모든 애플리케이션 분류 계층에 대해 구현하지 않기로 선택할 수 있는 보안 제어가 필요한 이러한 항목은 액세스 제어 솔루션 내부에서 "고위험"으로 정의되어야 합니다. 
• 원격 인증에는 여러 가지 요소가 필요합니다. 유효한 자격 증명을 사용하여 두 번째 인증 요구 사항을 충족하지 못하는 액세스 시도가 이루어지는 경우(공격자가 자격 증명이 공유된 침해로부터 유효한 자격 증명을 수집한 경우) 또는 마지막 유효한 로그인을 기준으로 물리적으로 불가능한 위치(예: 동유럽에서 동일한 사용자가 로그인을 시도하기 2시간 전 미국에서 성공적으로 로그인한 경우)에서 이루어지는 경우, 추가 보안 검토가 완료될 때까지 계정을 잠가야 합니다.
• 관리자 권한 접근은 업무 수행을 위해 정기적으로 이 수준의 접근이 필요한 적절하고 훈련된 인력에게만 허가되어야 합니다. 긴급 상황이나 특별 프로젝트를 위해 허용된 임시 액세스 권한은 자동 사용 모니터링이 설정된 다른 사용자 그룹에 속해야 하며, 이를 통해 시스템 관리자가 액세스 권한 제거를 잊었을 경우 이를 알려야 합니다. 접근 적절성 검토는 정기적으로 수행되어야 하며, 이해 상충을 피하기 위해 애플리케이션을 담당하는 팀이나 애플리케이션에 대한 접근 권한을 부여하는 팀과는 독립적으로 완료되어야 합니다. 권한이 있는 사용자가 장기간 계정에 접근하지 않는 경우, 실제로 해당 접근이 필요한지 의심해 보아야 합니다.
• 모든 권한이 있는 사용자의 애플리케이션 접근에 대한 적절한 회계가 기록되어야 합니다. 여기에는 사용자 계정에서 변경한 모든 내용이 포함됩니다.   

클라우드에서 액세스 제어에 대한 이 수준의 가시성과 자동화를 확보하는 일은 어렵고 비용이 많이 들 수 있습니다. 이러한 기능은 일반적으로 기본적으로 제공되지 않기 때문입니다. 하지만 제3자 라이선스를 이용하면 가능하며, 그 중요성을 감안하면 투자할 가치가 충분합니다.

애플리케이션의 꾸준한 성장과 공격자가 어떤 애플리케이션을 타겟으로 삼고 누가 해당 애플리케이션에 액세스할 수 있는지 파악하는 데 사용하는 미디어에 제공되는 풍부한 데이터로 인해 보안 인식 교육이 그 어느 때보다 중요해졌습니다.

스피어 피싱은 적의 행동 방식이므로 피싱 훈련에 주력해야 합니다. 2018년 F5 Labs 피싱 및 사기 보고서에 따르면 직원에게 10회 이상 교육을 실시하면 피싱 성공률이 33%에서 13%로 낮아질 수 있는 것으로 나타났습니다. 하지만 보안 인식 교육이 충분히 실시되거나 적절한 자료가 제공되는 경우는 드뭅니다. 규정 준수 사항을 확인하기 위해 설계된 틀에 박힌 인식 교육 서비스는 직원들이 정보 보안에서 자신의 역할을 이해하지 못하고, 이에 대한 개인적인 의무감을 느끼지 못할 위험이 있습니다. 침해 위험을 줄이는 것이 목표라면 조직에 맞게 개인화된 빈번한 교육을 실시하는 것이 가장 좋은 방법입니다.

공격자에게는 다운타임이 없으므로 직원은 항상 경계해야 합니다. 호기심을 키우는 지속적인 문화는 모든 조직, 특히 연방 분야나 연방 정부에 제품과 서비스를 공급하는 모든 기업에서 표준이 되어야 합니다. 직원들은 자신이 애플리케이션 및 데이터에 액세스하기 때문에 표적이 된다는 사실을 알고 있어야 합니다. 또한 그들은 그러한 접근 권한 또는 데이터가 적대적인 국가에 의해 어떻게 사용되는지, 또는 이익을 추구하는 사이버 범죄자에 의해 어떻게 판매되는지(그러면 적대자가 그것을 구매하는지)도 알고 있어야 합니다.

모든 조직은 디지털 혁신을 성공적으로 이루기 위해 엔터프라이즈 애플리케이션 전략과 해당 정책을 채택하고, 이에 대한 직원 교육을 실시해야 합니다. 기존, 하이브리드, 최신 애플리케이션이 다양하게 섞여 있는 연방 분야에서는 이러한 점이 특히 중요합니다. 안정적이고 안전하며 공인된 디지털 서비스를 제공하는 데 성공하려면 이것이 필요합니다.

애플리케이션은 모든 조직의 디지털 혁신의 핵심이며, 소프트웨어 개발 및 배포 방식의 빠른 변화로 인해 애플리케이션은 조직의 가장 큰 가치의 원천이자 가장 큰 취약성의 원천이 되었습니다. 여기에 설명된 애플리케이션 전략 및 정책 구성 요소는 모든 조직의 디지털 열망을 보호하는 데 필수적인 기반을 제공합니다. 애플리케이션 포트폴리오의 위험 프로필이 매일 증가함에 따라 조직에서는 전략과 정책을 신속하게 공식화해야 합니다.

¹ 관리 및 예산국 클라우드 스마트 전략

² F5 랩스: 10년간의 데이터 침해로부터 얻은 교훈

³ 범죄자들이 카지노에서 데이터를 훔치기 위해 수족관을 해킹하다 , Forbes

⁴ 컴퓨터월드, 기본 네트워크 분할 오류로 인해 타겟 침해 발생

⁵ 2018 소프트웨어 공급망 현황 , Sonatype