클라우드는 원래 간단해야 하는 것 아니었나요?
단일 클라우드를 사용하는 경우라면 대개 대답은 단연 ‘예’입니다. 하지만 주의할 점은 오늘날 대부분의 조직이 단일 클라우드만 사용하지는 않는다는 것입니다(F5의 2019 SOAS 보고서에서도 언급했듯이). 실제로는 여러 퍼블릭 및 프라이빗 제공업체를 조합해 사용하고 있습니다. 여러 클라우드를 도입하면 각각 고유한 인프라, 서비스, 도구뿐 아니라 서로 다른 인터페이스와 용어까지 사용하므로 운영 복잡성이 증가합니다. 멀티 클라우드 아키텍처를 간소화하려면 가능한 모든 요소를 표준화해야 합니다. 여러 환경에서 공통으로 사용할 수 있는 도구를 활용하면 이러한 복잡성의 상당 부분을 추상화하여 서비스 포트폴리오를 특정 클라우드 종속형에서 클라우드 독립형으로 전환할 수 있습니다.
멀티 클라우드 아키텍처에서 F5를 사용할 때 얻을 수 있는 여러 이점 중 하나는 환경 전반에서 F5 서비스가 일관되게 제공되므로 애플리케이션 서비스 정책을 여러 플랫폼에서 손쉽게 재사용하고 복제할 수 있다는 점입니다. 클라우드 전반에 일관된 정책을 적용함으로써 조직이 이점을 얻을 수 있는 몇 가지 상황을 자세히 살펴보겠습니다.
1) 멀티 클라우드 보안 취약점을 신속하게 패치
공통 프레임워크와 라이브러리를 사용하는 애플리케이션이 AWS, Azure 및 온프레미스 데이터 센터 전반에서 실행되는 상황을 가정해 보겠습니다. 보안은 비즈니스에 매우 중요하므로 각 애플리케이션 앞에 웹 애플리케이션 방화벽(WAF)을 배포했습니다. 클라우드 네이티브 서비스와 선택한 데이터 센터 공급업체의 솔루션을 함께 사용했다면, 이제 각 환경은 정책 구현 방식과 도구, 프로세스가 서로 다른 웹 애플리케이션 방화벽으로 보호됩니다. 그러다 구성 요소 중 하나에서 피할 수 없는 취약점이 발견되면 어떻게 해야 할까요?
멀티 클라우드 보안에 클라우드별 접근 방식을 채택했으므로, 문제를 해결하려면 각 WAF 정책을 개별적으로 검토하고 각각에 맞는 고유한 패치를 마련해야 할 가능성이 큽니다. 이는 결코 가장 빠르거나 간단한 작업이 아닙니다. 하지만 클라우드에 구애받지 않는 접근 방식을 채택하여 각 환경에 F5 WAF를 프로비저닝했다면, 모든 WAF 인스턴스에 적용되는 단일 정책 하나만 수정하면 되었을 것입니다. 또한 중앙 집중식 콘솔에서 API 호출이나 버튼 클릭 한 번으로 업데이트된 정책을 각 인스턴스에 자동 배포할 수 있어, 시간이라는 소중한 자원을 상당히 절약할 수 있습니다.
또한 해당 정책이 보안 팀의 사용 승인을 받으면 BIG-IQ 정책 카탈로그에 템플릿으로 저장할 수 있습니다. 그러면 DevOps 또는 앱 팀은 API 호출을 통해 사전 승인된 이 정책을 CI/CD 파이프라인으로 신속하게 가져와 엔드투엔드 앱 배포를 간소화할 수 있습니다. 이를 통해 SecOps는 모든 앱(신규 및 기존 앱 모두)에 최신 보안 정책이 적용된다는 확신을 가질 수 있으며, 애플리케이션 배포 프로세스도 가속화됩니다.
2) 원활하게 발전
기업에 장기적인 클라우드 전략을 물어보면, 클라우드 혁신 속도가 너무 빨라 확신을 갖고 미래를 예측하기 어렵기 때문에 대개 불확실성이 묻어나는 답변이 돌아옵니다. 대부분은 어떤 클라우드를 사용하고 있거나 사용할 계획인지 대략 알고 있지만, 플랫폼과 서비스가 끊임없이 발전하는 상황에서 앱에 가장 적합한 클라우드가 오늘도 내일도 최선일 것이라고 누구도 장담할 수 없습니다. 혁신적인 신규 클라우드 서비스로 인해 앱을 마이그레이션해야 할 수도 있고, 비용 분석 결과 다른 공급자를 이용하면 지출을 크게 줄일 수 있다는 사실이 드러날 수도 있습니다. IT 리더십의 변화로 클라우드 전략이 완전히 뒤바뀔 수도 있습니다. 이처럼 불확실성이 큰 상황에서는 새로운 클라우드나 인프라 도입에 따른 위험을 줄일 수 있도록 투자를 미래 지향적으로 설계하는 것이 중요합니다.
보안 시나리오와 마찬가지로 일관성이 도움이 될 수 있습니다. F5 애플리케이션 서비스는 기본적으로 모든 플랫폼에서 동일합니다. 이는 한 클라우드에서 다른 클라우드로, 또는 데이터 센터에서 클라우드로 마이그레이션해야 할 때 매우 중요합니다. 기존의 모든 서비스 정책, iRules 및 인스턴스 구성을 여러 환경에서 그대로 복제하고 재사용할 수 있기 때문입니다. 이를 통해 상당한 시간을 절약하고 마이그레이션을 크게 간소화할 수 있습니다. 하지만 저희의 말만 믿으실 필요는 없습니다. Gold Digest Online과 Alberta Motor Association 모두 기존 F5 서비스와 정책을 그대로 가져가 AWS로의 전환을 간소화했으며, 이 방식이 매우 유용하다는 사실을 확인했습니다.
3) 재해 복구 강화
프라이빗 데이터 센터와 상용 클라우드 제공업체 모두 때때로 장애를 겪으며, 일반적인 원인으로는 하드웨어 고장, 정전, 보안 침해 등이 있습니다. 이에 따라 많은 조직이 미션 크리티컬 및 비즈니스 크리티컬 애플리케이션의 가용성을 보장하기 위해 대체 위치뿐만 아니라 다른 공급업체를 통해서도 백업 재해 복구 사이트를 구축합니다. 이러한 재해 복구(DR) 사이트가 가동될 때 애플리케이션 사용자 경험에 영향이 없도록 하는 것이 중요합니다.
F5를 사용하면 액티브/스탠바이 HA 구성을 활용해 애플리케이션 요청을 기본 사이트에서 DR 사이트로 원활하게 페일오버할 수 있을 뿐만 아니라, 환경 전반에 걸쳐 고급 서비스를 일관되게 제공하여 사용자 경험을 동일하게 유지할 수 있습니다. F5의 구성 동기화 기능을 활용하면 기본 BIG-IP 디바이스에 적용된 모든 변경 사항을 DR 리전에 있는 디바이스를 포함한 전체 디바이스 그룹에 지속적으로 전파할 수 있습니다. iRules와 프로파일에서 SSL 인증서와 가상 IP에 이르기까지 모든 항목을 환경 간에 동기화하여 시스템 중단에도 비즈니스 연속성을 보장할 수 있습니다.
F5가 일관된 정책을 관리하는 데 어떻게 도움을 줄 수 있는지 자세히 알아보려면 여기를 클릭하세요.
작성자 소개
관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.