에이전트 없는 아키텍처와 에이전트 기반 아키텍처:중요한 이유는 무엇입니까?

클라우드용 보안, 분석 및 모니터링 솔루션의 영역에서 에이전트 없는 기반 아키텍처와 에이전트 기반 아키텍처에 대한 많은 논의가 있습니다. 에이전트가 없는 모니터링 제품과 에이전트가 없는 모니터링 제품을 평가하는 IT 전문가는 각각에 대한 장단점의 균등화를 발견할 것입니다. 눈에 띄는 승자는 상황에 따라 바뀝니다. 에이전트 없는 아키텍처와 에이전트 기반 아키텍처를 결정하는 것은 나중에 클라우드 환경을 보장할 수 있는 능력과 마찬가지로 규정 준수 및 보안을 위한 일상적인 작업의 숙련도에 큰 영향을 미칠 수 있습니다. 각 선택 간의 차이점을 이해하고 이 선택과 관련된 장단점을 완전히 염두에 두는 것이 중요합니다.

차이점은 무엇입니까?

에이전트 없는 아키텍처와 에이전트 기반 아키텍처는 데이터를 수집하고 클라우드 환경의 요소(데이터베이스 서비스, 네트워크, 로드 밸런서, 서버 인스턴스, 보안 그룹 등)를 제어하는 ​​방식에 따라 근본적으로 다릅니다. 에이전트 기반 보안 제품을 사용하는 경우 모든 서버에 작은 소프트웨어 에이전트를 설치해야 합니다. 에이전트는 설치된 서버에서 중요한 데이터를 수집하고 데이터를 다시 중앙 제어 프레임워크로 보내고 가상 머신/서버 인스턴스 수준에서 보안 조치를 제어할 수 있도록 합니다. 예를 들어, 에이전트 기반 보안 제품은 호스트 방화벽 배치 및 서버 간의 시스템 트래픽 스트리밍에 대한 데이터를 축적하고 파일 무결성 모니터링 및 각 호스트에 방화벽을 설치할 수 있는 용량을 제공합니다.

에이전트 없는 아키텍처는 서비스 제공자의 API를 통해 기본 클라우드 플랫폼(예:MS Azure, AWS)과 직접 대화하여 사례, 관리, 시스템에 대한 데이터를 얻고 보안을 제어합니다. 에이전트리스는 플랫폼과 직접 대화하기 때문에 클라우드 환경의 일부인 리소스를 변경할 필요가 없습니다. 이 때문에 API 기반 서비스 또는 클라우드 네이티브라고도 하는 에이전트 없는 아키텍처는 현재 진행 중인 애플리케이션과 뛰어난 작업에 대해 완전히 명확합니다.

30일 무료 평가판 시작 CloudInstitute.io에서 전문가와 연결하여 클라우드 인증에 대해 자세히 알아보세요.

왜 차이가 있습니까?

워크로드 보안 플랫폼은 퍼블릭 클라우드 환경을 위해 처음 출시되었을 때 에이전트 기반으로 설계되었습니다. 그러나 이 모든 것은 클라우드 전문 서비스 제공업체가 제공하는 보안 시스템이 계속 발전하고 있으며 초기에는 오늘날처럼 유능하고 강력하지 않았기 때문에 제한적인 범위였습니다. 이러한 도구는 또한 당면한 미해결 작업을 퍼블릭 클라우드로 이전한 조직에 데이터 센터 환경을 위해 생성된 도구를 퍼블릭 클라우드 환경으로 가져갈 수 있는 접근 방식을 제공했습니다. 이것은 그들 중 일부에게 오픈 클라우드로의 진행을 더 간단하게 만드는 데 도움이 되었습니다.

그러나 보다 정적이고 놀라운 데이터 센터 환경을 위한 에이전트 기반 아키텍처는 퍼블릭 클라우드 환경의 끊임없이 변화하는 환경에 무력하게 적합합니다. 그 이유를 살펴봐야 합니다.

그럼에도 불구하고 전 세계 여러 VPC에 걸쳐 수백 개의 가상 머신 또는 서버 인스턴스로 둘러싸여 있고 여러 레코드에 도달하고 레코드가 정기적으로 환경에 포함되고 지워지는 클라우드 상황에서 모든 이벤트를 감독하는 복잡성 , 에이전트처럼 기본적인 것이 엄청난 무게로 변합니다. 에이전트 관리는 클라우드 환경에서 또 다른 작은 약점을 제공합니다. 최근에 시작된 Rouge 인스턴스에 설치된 에이전트가 제대로 작동하는지 확인할 수 있습니까? 각기 다른 전문 부서와 파트너가 있는 상황에서는 에이전트가 각 인스턴스에 올바르게 설치되도록 보장하는 자체 시스템이 특히 어렵습니다.

1. FaaS에 에이전트를 도입할 여지가 없음: 5년 전 AWS를 보면 대부분의 벤처가 S3, EBS, EC2 등 2~4개 서비스만 제공했다. EC2 인스턴스에 에이전트를 도입하고 상태를 완전히 보장할 수 있습니다.

현재 수많은 조직에서 기본 데이터베이스 서비스(RDS, DynamoDB), 빅 데이터 서비스(ElasticSearch, EMR) 및 로드 밸런서(ELB)를 효과적으로 활용하고 있습니다. AWS Lambda(서버리스 컴퓨팅이라고도 함)와 같은 FaaS 제품이 추가로 주류가 되고 있습니다. 이러한 경우 에이전트를 배치할 장소가 없거나 환경에 에이전트를 배치할 수 없습니다(그래서 에이전트는 Lambda 환경에서 어디에 적합합니까?). 에이전트 기반 솔루션은 이러한 서비스를 선별하거나 보장하는 것을 완전히 무시합니다. 지금은 Lambda 서비스 사용이 필요하지 않을 수 있지만 나중에 검사하고 보장할 수 있는 항목을 제한하는 클라우드 보안 솔루션이 필요하십니까?

더 읽어보기:클라우드 보안 위험 관리 방법

1. 클라우드 네이티브 서비스에 익숙하지 않음: 그러나 에이전트 기반 보안 제품은 RDS 및 ELB와 같은 클라우드 네이티브 관리를 소홀히 할 뿐만 아니라 이러한 서비스가 인스턴스 보안 전략에서 시연되는 것을 허용하지 않습니다. 예를 들어 보안 전략에서 인스턴스가 RDS로만 아웃바운드 트래픽을 보낼 수 있고 ELB에서 들어오는 연결을 얻을 수 있음을 나타내는 것은 극히 가능성이 낮습니다. 이러한 장애로 인해 지나치게 관대한 "모두에게 개방된" 접근 방식으로 전환해야 합니다.
2. 클라우드에 구애받지 않는 방식으로 규정 준수를 보장하고 보안을 유지하는 것은 하이브리드 클라우드 환경은 물론 AWS 및 Azure에서 실행되는 부담이 남아 있고 단독으로 묶이고 싶지 않은 멀티 클라우드 배포에 중요합니다. 하나의 특정 플랫폼으로 에이전트 도입 및 감독 없이도 클라우드에 구애받지 않는 보안 관리를 수행할 수 있습니다. 클라우드 보안 플랫폼을 사용하면 클라우드에 구애받지 않는 방식으로 솔루션과 규칙을 표시하고 보안 접근 방식을 구현하고 구현하기 위해 각 클라우드의 기본 기능을 활용하여 다양한 퍼블릭 클라우드 환경의 보안 입장을 처리할 수 있습니다. 다양한 클라우드에 대해 보안 전략을 한 번 표시하고 이후에는 각 클라우드에서 제공하는 놀라운 제어 기능을 활용하여 이를 실행할 수 있기 때문에 두 세계를 혼란스럽게 만듭니다.
3. AWS 환경의 에이전트 기반 아키텍처에 대해 무의미한 세금을 지불해야 합니다. 에이전트 기반 솔루션을 사용하면 각 인스턴스에서 에이전트가 작동하고 CPU 사용을 줄인다는 사실 외에도 이러한 에이전트가 도움 규제 기관과 대화하고 클라우드 환경에서 데이터 전송을 확장하게 됩니다.

에이전트 대 에이전트 없는 아키텍처 딜레마

IT 배치와 비즈니스 자체가 에이전트 없는 아키텍처와 에이전트 없는 아키텍처에 대한 가장 적절한 대응을 결정합니다. 일반적인 조직 실행의 핵심 동인으로 데이터 기술에 의존하는 조직. 예를 들어, 예산 관리 공급자는 에이전트 기반 프레임워크가 전달하는 깊이가 필요할 수 있습니다. 다운타임이나 시스템 병목 현상이 주요 관심사에 최소한의 영향을 미치는 회사는 에이전트 없는 방법론의 수월함을 더욱 매력적으로 발견할 수 있습니다.

기업은 마찬가지로 에이전트 및 에이전트 없는 아키텍처를 혼합하고 일치시킬 준비가 되어 있습니다. 조직에는 프레임워크 정보를 수집하기 위한 두 가지 대안이 있습니다. 그것은 둘 중 하나/혹은 선택이 아닌 모든 것입니다. IT 구성 요소와 비즈니스에 대한 아이디어를 생각하고 그 시점에서 에이전트 또는 에이전트 없는 방법론이 특정 요구 사항에 가장 적합한지 결정합니다.

에이전트 없는 기술은 데이터를 복구하기 위해 시스템의 기본 설치된 관리 유용성을 활용하는 것입니다. 기술이 에이전트 없는 것으로 명명되었는지 여부에 관계없이 가제트에서 정보를 복구하려면 리소스를 소모하는 하나 이상의 주기를 실행해야 합니다.

탐색 단계에서는 몇 가지 정보 소스를 활용할 수 있으며 조직적인 확인을 위해서는 에이전트리스가 가장 좋습니다. 그러나 지출을 업그레이드하고 예산 프레젠테이션을 줄이려면 결국 에이전트를 배치해야 합니다. 문제는 언제 ?

에이전트 없는 기술의 이점은 추가 소프트웨어 도입과 관련된 장애물을 제거한다는 것입니다. 이는 현재 사용 중인 기계, 특히 서버 팜에서 실행되는 중요한 작업자에게 중요하지 않은 주기가 될 수 있습니다. 보안 규칙, 소프트웨어 불일치 문제, 최신 변형 에이전트 설치 보장, 수많은 장치에서 에이전트를 새로 고치는 오버헤드는 IT 사무실이 소프트웨어 배포와 관련하여 직면하는 장애물의 일부일 뿐입니다. 그럼에도 불구하고 에이전트리스의 문제는 이러한 기술이 소프트웨어 지출을 향상시키기에 충분한 데이터를 제공하지 않는다는 것입니다.

결론

다른 아키텍처와 마찬가지로 오늘날의 문제를 해결하고 추진하는 비즈니스 패턴을 지원하는지 확인하려면 신중한 생각과 핵심적인 검사를 수행해야 합니다. 기술, 보안 및 향상된 지원의 핵심 이점을 감안할 때 에이전트 없는 구조는 DevOps 도구와 동일하므로 에이전트 기반 계획보다 최고의 선택입니다. CloudInstitute.io는 클라우드 컴퓨팅 및 사물 인터넷과 함께 사물의 방식을 예상하면서 에이전트 없는 아키텍처가 확실히 가장 적합하다고 믿습니다.

클라우드 컴퓨팅 분야에서 경력을 시작하는 데 관심이 있으십니까? CloudInstitute.io는 가장 저렴한 클라우드 컴퓨팅 인증 과정을 제공합니다. 더 많이 성장하려면 자세히 알아보세요!

전문가와 연결하고 성공적인 클라우드 경력을 위한 미래의 노력을 계획하십시오. 지금 30일 무료 평가판을 시작하십시오!