이 글에서는 2016년 9월과 10월에 발생한 전례 없는 #DDoS 공격의 영향을 간략히 살펴보고, 복원력을 강화하고자 하는 분들을 위한 지침을 제공합니다.

사물 인터넷 시대가 도래한 것을 축하합시다! 마침내 사물 인터넷이 현실이 되었다는 사실은 9월부터 세 차례나 사이버 무기로 사용되었다는 데서 알 수 있습니다. 그 시작은 블로거이자 언론인인 브라이언 크렙스를 겨냥한 대규모 공격이었습니다. 그의 웹사이트인 krebsonsecurity.com은 CDN 업체 Akamai가 호스팅하고 보호하고 있었습니다. 공격이 너무 심각해 Akamai의 다른 고객들에게까지 영향을 미치자, Akamai는 이 블로거에게 무상으로 제공하던 방어 서비스를 중단했습니다.
F5 연구진을 포함한 업계 연구자들은 DVR, 비디오카메라 및 기타 ‘사물’로 구성된 새로운 봇넷의 출현을 감지했습니다. 특히 DVR과 비디오카메라가 주목되는 이유는 정교한 멀웨어를 구동할 수 있을 만큼 CPU 성능이 뛰어난 데다, 각각 최대 100Mbps 규모의 공격을 감행할 수 있는 고대역폭 업링크까지 갖추고 있기 때문입니다. 크렙스를 겨냥한 전체 공격 트래픽은 620Gbps에 달했으며, 당시 세계 최대 규모의 DDoS 공격이었습니다.
두 번째 공격으로 프랑스 최대 호스팅 제공업체인 OVH(관련 자료에 따르면 세계 3위)가 하루 중 상당 시간 동안 마비되었습니다. 많은 언론 보도에서는 OVH 공격의 규모가 크렙스 공격의 거의 두 배 수준인 초당 1테라비트에 달했다고 전했습니다.
세 번째이자 어쩌면 최악이었던 공격은 DNS 서비스 업체인 Dyn을 겨냥했습니다. Dyn은 Twitter, Spotify, GitHub(공교롭게도 IoT 봇넷 코드가 게시된 곳)를 비롯한 여러 유명 웹사이트에 DNS 서비스를 제공하는 업체입니다.
그렇다면, 누가 한 짓일까요?
공교롭게도 업계의 저명인사인 브루스 슈나이어는 그 전 달 여러 매체와 인터뷰를 하며 국가 차원의 대규모 DDoS 공격이 곧 닥칠 것이라고 경고해 왔다. 그의 내부 정보는 인터넷 핵심 인프라를 겨냥한 탐색성 DDoS 공격을 포착한 익명의 업계 소식통들에게서 나온 것이었다.
하지만 알고 보니, 그러한 탐색 공격은 단지 우연의 일치였을 수도 있습니다. 슈나이어 본인도 자신의 블로그에서 Dyn 공격의 배후가 국가라고는 전혀 생각하지 않는다고 인정했습니다. 하지만 어쩌면 그 국가는 그저 지켜보며 때를 기다리고 있는지도 모릅니다.
Krebs, OVH, Dyn 사건의 배후를 밝힐 열쇠는 아마도 Brian Krebs 본인에게 있을 것입니다.
“DYN에 대한 공격은 DYN 연구원인 Doug Madory가 텍사스주 댈러스에서 열린 북미 네트워크 운영자 그룹(NANOG) 회의에서 DDoS 공격에 관해 발표한 지 불과 몇 시간 만에 발생했다. …또한 KrebsOnSecurity.com을 겨냥한 기록적인 620Gbps 규모의 DDoS 공격도 Madory와 내가 공동으로 취재한 기사를 내가 게시한 지 불과 몇 시간 만에 발생했다.”
공격자는 브라이언 크렙스나 더그 매도리, 또는 두 사람 모두에게 악의를 품은 개인(또는 소규모 집단)일 가능성이 매우 높습니다.
중국과 미국 간에 전면적인 사이버전이 벌어지면 수백만 명의 사용자가 영향을 받으리라는 것은 누구나 이해할 수 있습니다. 하지만 이 모든 일이 한 개인이 다른 한 개인을 겨냥해 벌인 사적인 행동으로 밝혀진다면 어떨까요? 이는 국가 차원의 공격보다도 더 무서운 일입니다. 한 사람에게 원한을 품은 개인이 수백만 명이 이용하는 핵심 서비스를 마비시킬 수 있다면, 우리는 대체 어떤 인터넷을 만들어 온 것일까요?
어쩌다 이렇게 되었을까요?
F5는 1년 넘게 사물 인터넷(IoT) 기기를 노리는 활동을 모니터링해 왔습니다. 이 문제에 관한 첫 번째 보고서는 2016년 7월에 발표되었으며, 텔넷 및 SSH 무차별 대입 스캔이 전년 대비 140% 증가한 것으로 나타났습니다. 텔넷과 SSH는 원격 관리에 널리 사용되는 포트로, 공급업체가 설정한 기본 사용자 이름과 비밀번호(또는 쉽게 추측할 수 있는 사용자 이름과 비밀번호)를 그대로 사용한 채 자신도 모르게 인터넷에 노출되는 경우가 많습니다.
2016년 10월 Krebs, OVH, Dyn을 대상으로 발생한 전례 없는 DDoS 공격에서는 바로 이 기법(IoT 기기의 텔넷 포트와 공급업체 기본 비밀번호를 스캔하는 방식)을 사용해 독보적인 성능을 갖춘 봇넷을 구축했습니다.
다시 모두가 표적이 되었습니다. 봇넷 운영자들은 자신들의 사이버 무기를 세계 최대 규모의 서비스 제공업체들에 겨누는 것도 두려워하지 않습니다. 이전에는 감히 건드릴 수 없다고 여겨졌던 표적들입니다.
이러한 공격이 하룻밤 사이에 일어난 것처럼 느껴질 수 있지만, 실제로 봇넷 운영자는 최소 1년 동안 취약한 IoT 기기를 서서히 탐색하고 찾아내 장악해 왔습니다.
현재까지 알려진 내용 심층 분석
실제로 우리는 IoT 봇넷인 Mirai의 기능을 상당히 잘 파악하고 있습니다. F5의 연구원들은 Mirai 봇의 제작자가 hackforums.net에 소스 코드를 공개한 직후 이 봇을 기술적으로 상세히 분석한 글을 작성했습니다.
이들의 총공격력은 이전 봇넷보다 한 자릿수 이상 강력해 초당 수 테라비트를 웃돌 가능성이 높습니다.
IoT 봇넷은 다음과 같은 고급 DDoS 기법을 포함하며, 이에 국한되지 않습니다. 아래의 구체적인 지침 섹션에서는 가능한 경우 이러한 공격을 완화하는 방법을 권고합니다.
리디렉션에 내성을 지닌 HTTP GET 플러드
HTTP GET 플러드 공격은 이미 매우 위협적이었습니다. 공격자들은 수년 동안 대용량 객체나 처리 속도가 느린 데이터베이스 쿼리를 요청하는 HTTP 요청을 대량으로 전송해 웹사이트를 마비시킬 수 있었습니다. 일반적으로 이러한 요청은 하드웨어 기반 패킷 처리를 사용하는 대부분의 장비에서 정상적인 HTTP 요청처럼 보이기 때문에 표준 방화벽을 그대로 통과합니다. Mirai 공격 코드는 여기서 한발 더 나아가 클라우드 기반 DDoS 스크러빙 장비의 특성을 식별한 다음, 해당 장비가 반환하는 모든 302 리디렉션을 우회합니다. 리디렉션은 단순한 봇을 저지하는 데 효과적인 방법이었지만, 이 봇은 단순하지 않습니다.
DNS 워터 토처
Mirai 봇에는 대상 DNS 제공업체를 겨냥한 ‘워터 토처(water torture)’ 공격 기능이 포함되어 있습니다. 이 기법은 봇이 훨씬 적은 수의 쿼리만 전송하고 ISP의 재귀 DNS 서버가 대상 권한 DNS 서버를 공격하도록 한다는 점에서 일반적인 DNS 반사 및 증폭 공격과 다릅니다. 이 공격에서 봇은 확인하려는 대상 도메인 이름에 무작위로 생성한 접두사를 붙여 올바른 형식의 DNS 쿼리를 전송합니다. 대상 DNS 서버가 과부하되어 응답하지 못하게 되면 공격이 효과를 발휘합니다. 그러면 ISP의 DNS 서버는 대상 조직의 다른 권한 DNS 서버에 질의하기 위해 쿼리를 자동으로 재전송하며, 결과적으로 봇을 대신해 해당 서버들을 공격하게 됩니다.

Dyn은 자사 블로그 게시물인 10월 21일 금요일 공격에 대한 Dyn 분석 요약에서 실제로 자사를 상대로 워터 토처 공격이 사용되었다고 확인했습니다.
“예를 들어, 공격의 영향으로 재귀 서버가 캐시를 새로 고치려고 시도하면서 정상적인 재시도 요청이 폭증했고, 그 결과 수많은 IP 주소에서 평소보다 10~20배 많은 트래픽이 발생했습니다. DNS 트래픽 정체가 발생하면 정상적인 재시도 요청으로 인해 트래픽 양이 더욱 증가할 수 있습니다.
악의적인 공격은 최소 하나의 봇넷에서 시작된 것으로 보이며, 재시도 폭증으로 인해 실제로 확인된 것보다 훨씬 더 많은 엔드포인트가 있는 것처럼 잘못 파악되었습니다. 아직 데이터를 분석 중이지만, 이 보고서 작성 시점의 추정치로는 최대 100,000개의 악성 엔드포인트입니다.”
F5 연구원 리론 세갈은 몇 주 전 게시한 글 ‘크렙스를 마비시킨 봇, 미라이’에서 봇의 워터 토처 공격 메커니즘을 자세히 설명한 바 있습니다.
업데이트된 계층 4 공격
봇 제작자에 따르면, 이른바 ‘TCP STOMP’ 공격은 완화 장치를 우회하기 위한 단순 ACK 플러드 공격의 변형입니다. 이 공격의 실제 구현 방식을 분석한 결과, 봇은 완전한 TCP 연결을 수립한 다음 연결을 유지하기 위해 유효한 시퀀스 번호가 포함된 ACK 패킷을 계속해서 대량으로 전송하는 것으로 보입니다.
새로운 IoT 봇의 개별 위협 벡터에 대한 이해를 바탕으로, 각 위협 벡터를 완화하기 위한 몇 가지 지침을 제시할 수 있습니다.
지침을 설명하기에 앞서 분명히 짚고 넘어가겠습니다. Krebs, OVH, Dyn 공격은 그 자체로 차원이 다른 공격이었습니다. 기존 DDoS 완화 기술로는 공격자들을 쉽게 물리치지 못했고, 그 결과 서비스 중단이 발생하고 언론의 헤드라인을 장식했습니다. 하지만 많은 경우 결국 완화 조치가 실제로 효과를 발휘했습니다 . 또한 Anycast와 분산된 데이터 센터를 사용하는 등 적절한 아키텍처도 도움이 되었습니다. 미국 서부 해안과 서부 지역은 Dyn 공격의 영향을 거의 받지 않았다는 점에 주목할 필요가 있습니다.
권장 지침
당사의 지침은 고객들의 실제 경험을 바탕으로 합니다. F5는 20년 동안 세계적인 유명 브랜드의 애플리케이션을 제공해 왔으며, 이들 고객 중 상당수는 매일 DDoS 공격을 받고 있습니다. 경험이 가장 풍부한 고객들은 방어 체계를 다음과 같이 3~4개의 영역으로 구분합니다:
- 클라우드 스크러빙
- 네트워크 방어
- 애플리케이션 방어
- 해당되는 경우 DNS
따라서 최상의 DDoS 방어 아키텍처는 다음과 같습니다:

이는 F5 고객들이 수년간 널리 사용해 온 DDoS 방어 참조 아키텍처입니다. 전체 참조 아키텍처와 권장 사례는 F5.com에서 확인할 수 있습니다. 다만 빠르게 살펴볼 수 있도록 이러한 공격과 관련된 지침을 아래에 자세히 설명합니다.
대용량 공격 방어
프랑스 호스팅 업체 OVH는 990Gbps 규모의 볼류메트릭 공격을 받았습니다. Dyn 공격은 최고 1.2Tbps에 달한 것으로 알려졌습니다. 이 정도 규모의 공격은 일반적으로 대규모 방어에 특화된 클라우드 스크러빙 서비스를 통해서만 완화할 수 있습니다. F5의 Silverline DDoS Protection을 비롯한 클라우드 스크러빙 서비스는 공격 트래픽을 가로채 정제한 후, 사전에 구성된 터널을 통해 정상 트래픽만 대상 시스템으로 전송합니다.
권고 사항: 조직은 공격을 받기 전에 하나 이상의 클라우드 스크러빙 서비스 제공업체와 계약을 체결해 두어야 합니다. 사전 구성된 터널은 대규모 트래픽 공격이 진행되는 도중에 손쉽게 설정할 수 있는 것이 아닙니다. DDoS 전략의 일환으로 클라우드 스크러빙 DDoS 방어 서비스를 계약하십시오.
지침: 대규모 트래픽 공격에는 공격 분산이 도움이 될 수 있습니다. DNS 역시 도움이 될 수 있다는 점을 기억하세요. 복제된 콘텐츠를 제공하는 전 세계 데이터 센터에 애니캐스트를 적용하면 DDoS 공격 발생 시 공격 트래픽을 분산할 수 있습니다. 애니캐스트에 참여하는 각 데이터 센터가 공격 트래픽을 나누어 처리하는 데 도움이 됩니다.
관련 자료:
- F5 Silverline DDoS – 배포 방법
- F5 DDoS 플레이북: 실시간 DDoS 대응을 위한 10단계
- F5 DDoS 보호 권장 사례
- F5 DDoS 참조 아키텍처
네트워크 방어
Mirai 봇은 표준 SYN 플러드, TCP 플러드, UDP 플러드 등 여러 계층 4 공격 수단을 갖추고 있습니다. 이러한 오래된 위협 벡터는 클라우드 스크러빙 센터에서 완화하거나, 규모가 충분히 작은 경우 데이터 센터의 네트워크 방어 계층에서 완화해야 합니다. 네트워크 방어 계층은 네트워크 방화벽을 중심으로 구축됩니다. 이 계층은 SYN 플러드 및 ICMP 단편화 플러드와 같은 연산 자원 고갈 공격을 완화하도록 설계되었습니다. 또한 인입 지점에 정체가 발생하기 전까지(일반적으로 회선 정격 용량의 80~90%) 대용량 공격을 완화합니다.
지침: 많은 방화벽은 올바르게 구성하지 않으면 DDoS 공격을 견디지 못합니다. 관련 설정은 네트워크 방화벽 공급업체에 문의하십시오. 일부 고객은 계층 4 공격을 차단하기 위해 방화벽 앞단에 DDoS 방어 장비를 배치합니다.
지침: F5 방화벽 모듈(BIG-IP Advanced Firewall Manager (AFM))은 계층 4 공격을 방어하도록 특별히 설계되었습니다. 일부 아키텍트는 바로 이러한 용도로 BIG-IP AFM을 기존 네트워크 방화벽 앞에 배치하거나 기존 방화벽을 대체하여 사용합니다. AFM이 탑재된 하드웨어 어플라이언스는 FPGA(Field-Programmable Gate Array)를 사용하여 30가지가 넘는 패킷 플러드 공격을 방어하고 CPU의 작업 부담을 줄입니다.
관련 자료:
- BIG-IP AFM을 통한 DDoS 완화
- F5 BIG-IP Advanced Firewall Manager 데이터시트
- BIG-IP 12.1의 강력한 F5 보안 기능 10가지
- F5 DDoS 보호 권장 사례
애플리케이션 방어
Mirai 봇은 엄청난 규모의 HTTP GET 플러드 공격을 생성하고 리디렉션도 처리할 수 있습니다. GET 플러드 공격은 네트워크 방어 장비에 정상 트래픽처럼 보이므로 애플리케이션 계층에서 처리해야 합니다. GET 플러드 공격은 F5에서 관찰되는 애플리케이션 계층 공격 유형 중 단연 가장 흔하며, 고객이 사용하는 제품 포트폴리오에 따라 이를 완화할 수 있는 방법도 다양합니다.
지침: 단순 리디렉션을 처리할 수 있는 봇의 경우, F5는 초당 요청 수 지표를 기준으로 연결을 제한하거나 이른바 ‘로그인 장벽’을 사용할 것을 권장합니다. 로그인 장벽을 사용하면 연결이 데이터베이스 쿼리와 같이 캐시되지 않은 리소스나 동적 리소스를 사용하기 전에 애플리케이션에서 인증을 받아야 합니다.
관련 자료:
DNS 방어
Dyn 공격과 관련해 살펴볼 만한 DNS 문제는 두 가지입니다. 첫 번째이자 가장 명확한 문제는 새로운 유형의 공격 중 하나로 인해 DNS 제공업체가 오프라인 상태가 되었을 때 어떻게 대처해야 하는가입니다. Dyn은 Twitter, GitHub, Spotify의 네임 서비스 제공업체였기 때문에 Dyn이 차단되자 최종 사용자들은 이러한 서비스의 IP 주소를 찾을 수 없었습니다.
권고 사항: 중요 애플리케이션의 주소를 제공할 수 있도록 여러 DNS 공급자를 활용하는 등 DNS 계획에 복원력을 확보하십시오. 이렇게 하면 공급자 중 하나가 일시적으로 공격을 받아 서비스가 중단되더라도 다른 공급자가 주소를 제공할 수 있습니다. 최종 사용자의 접속 속도가 몇 밀리초 정도 느려질 수는 있지만, 애플리케이션과 서비스는 계속 이용할 수 있습니다.
두 번째 문제는 자체 DNS 서버가 공격받을 경우 어떻게 대응할 것인가입니다. DNS는 가장 빈번하게 공격 대상이 되는 서비스이며, HTTP가 그 뒤를 잇습니다. DNS에 장애가 발생하면 단일 애플리케이션뿐만 아니라 외부에 제공되는 모든 데이터 센터 서비스가 영향을 받습니다. 이처럼 전체 장애를 초래할 수 있는 단일 장애 지점이라는 점과 DNS 인프라의 용량이 충분히 확보되지 않는 경우가 많다는 점 때문에 DNS는 공격자들에게 매력적인 표적이 됩니다.
자체 서버가 공격받고 있지 않더라도, 하위 구간에서 장애가 발생하면 다른 DNS 서버들이 자체 캐시를 채우려는 과정에서 여러분의 DNS 서버로 요청을 폭주시킬 수 있다는 점을 기억하십시오. Dyn은 이러한 상황이 발생했을 때 평소보다 10~20배 많은 요청이 들어왔으며, 이는 상황에 대처하려던 정상적인 DNS 서버에서 보낸 요청이었다고 보고했습니다.
지침: 상당수의 DNS 서비스는 리소스가 충분히 프로비저닝되지 않아 소규모에서 중간 규모의 DDoS 공격조차 견디지 못합니다. DNS 캐시는 DNS 서비스의 체감 성능을 높이고 일반적인 DNS 쿼리 공격에 어느 정도 대응할 수 있어 널리 사용되고 있습니다. 공격자들은 이른바 ‘존재하지 않는 도메인’(또는 NXDOMAIN) 공격으로 전환했으며, 이러한 공격은 캐시가 제공하는 성능상의 이점을 빠르게 소진시킵니다.
F5는 F5 고객에게 F5 DNS Express™라는 DNS 프록시 모듈을 DNS 서비스의 프런트엔드에 배치할 것을 권장합니다. DNS Express는 기존 DNS 서버 앞에서 권한 있는 리졸버 역할을 합니다. 서버에서 영역 정보를 불러와 모든 요청을 처리하거나 NXDOMAIN을 반환합니다. 이는 캐시가 아니므로 NXDOMAIN 쿼리 플러드로 인해 비워질 수 없습니다.
지침: DNS는 DDoS 공격 시 유용한 방어 수단이 될 수 있다는 점을 기억하십시오. 복제된 콘텐츠를 제공하는 전 세계 데이터 센터에 애니캐스트를 적용하여 DDoS 공격 발생 시 공격 트래픽을 분산하십시오.
지침: DNS 서비스의 배치를 고려하세요. DNS 서비스는 첫 번째 보안 경계와 분리된 독립적인 장치 집합으로 구성되는 경우가 많습니다. 이는 DNS가 서비스를 제공하는 애플리케이션과 독립적으로 운영되도록 하기 위한 것입니다.
여러 데이터 센터를 운영하는 일부 대기업은 BIG-IP DNS와 DNS Express 및 BIG-IP AFM 방화벽 모듈을 함께 사용하여 기본 보안 경계 외부에서 DNS를 제공합니다. 이 접근 방식의 주요 이점은 DDoS로 인해 네트워크 방어 계층이 오프라인 상태가 되더라도 DNS 서비스를 계속 사용할 수 있다는 것입니다.
관련 자료:
- F5 프라이데이: DNS가 없다고요? 그럼…아무것도 안 됩니다
- F5 DNS 데이터시트
- DevCentral: DNS Express 및 영역 전송
- DevCentral: DNS Express - 1부
- 동적 DNS 인프라
- F5 DDoS 보호 권장 사례
- F5 DDoS 참조 아키텍처
결론
Krebs, OVH, Dyn을 겨냥한 공격은 DDoS가 새로운 국면에 접어들었음을 보여줍니다. 동시에 사물 인터넷이 본격적인 성숙기에 들어섰음을 의미하기도 합니다.
보시다시피 F5는 DDoS를 연구하고 방어하며 관련 글을 작성해 온 풍부한 경험을 보유하고 있으며, 고객의 애플리케이션이 지속적으로 가용한 상태를 유지할 수 있도록 고객과 협력하고자 합니다. 이를 위해서는 F5부터 파트너, 고객에 이르기까지 우리 모두가 경각심을 갖고 주의를 기울여야 합니다.
고객이든 아니든 공격을 받게 되면, F5 Silverline DDoS Protection 서비스를 전화 한 통으로 이용할 수 있다는 점을 기억하십시오: 866-329-4253.
IoT 위협과 관련해, 블랙햇 해커들은 늘 서로 정보를 공유합니다(Mirai가 Krebs와 OVH를 공격한 후 이를 공유했고, 이후 Dyn 공격에 사용되었습니다). 우리 정보 보안 커뮤니티도 이들의 방식을 본받아 힘을 합쳐 전 세계적인 IoT 문제를 해결해야 합니다. 우리에게는 다른 선택지가 없습니다. 문제를 이해하고 해결함으로써 진화하는 것이 인간의 본성이기 때문입니다.
향후 몇 년 동안 공격 규모가 커지고, 이러한 대규모 공격을 처리하기 위해 트래픽 정화 서비스의 대역폭이 확장되며, IoT 기기 제조업체들이 자사 기기의 보안 취약성에 대처할 방법을 찾아가는 과정에서 여러 차질이 생길 것은 분명합니다. 조직과 소비자는 과거의 다른 모든 중대한 문제에 그랬듯이, 계속 진화하는 이 위협에 익숙해져야 합니다.
작성자 소개
관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 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 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.