수집 스크립트는 결과를 보관 파일 (zip 또는 tar)에 저장하고 검색 클라이언트가 이를 검색합니다.
수집 메커니즘
탐색 클라이언트는 다음 섹션에 설명된 수집 메커니즘 중 하나 이상을 사용하여 대상 머신에서 데이터를 수집할 수 있습니다.
SSH (Linux)
SSH 수집 중에 다음 프로세스가 실행됩니다.
수집기 머신과 대상 서버 간에 SSH 세션이 시작됩니다.
~/.mcdc-temp/ 아래에 임시 디렉터리가 생성됩니다.
수집 스크립트가 해당 디렉터리에 복사됩니다.
수집 스크립트가 실행됩니다.
결과 보관 파일은 SCP를 사용하여 가져옵니다.
임시 디렉터리가 정리됩니다.
WMI (Windows)
Windows에서 WMI 수집이 진행되는 동안 다음 프로세스가 발생합니다.
대상 머신에 대한 WMI 연결이 시작됩니다.
대상 머신에서 HKLM:\SOFTWARE\Google\Collector\data 아래에 임시 (휘발성) 레지스트리 키가 생성됩니다.
수집 스크립트가 레지스트리 키에 복사됩니다.
C:\temp 아래에 임시 디렉터리가 생성됩니다.
수집 스크립트가 임시 디렉터리에 작성됩니다.
수집 스크립트가 실행됩니다.
수집 결과는 휘발성 레지스트리 키에 기록됩니다.
결과가 수집기 머신에 복사됩니다.
VMware 게스트 도구 (Linux 및 Windows)
Linux와 Windows 모두에서 VMware 수집이 진행되는 동안 다음 프로세스가 발생합니다.
VMware 게스트 도구를 사용하여 임시 디렉터리가 생성됩니다.
수집 스크립트가 해당 디렉터리에 복사됩니다.
수집 스크립트가 실행됩니다.
결과 보관 파일은 VMware 게스트 도구를 사용하여 가져옵니다.
임시 디렉터리가 정리됩니다.
주기적 데이터 수집
탐색 클라이언트는 주기적으로 구성된 모든 서버에서 데이터를 수집합니다. 컬렉션에는 두 가지 유형이 있습니다.
전체 수집: 서버별로 하루에 한 번 실행됩니다. 이 수집은 하드웨어, 환경, 설치된 소프트웨어, 실행 중인 프로세스 등 VM의 다양한 정보를 수집하는 전체 수집 스크립트를 실행합니다.
성능 수집: 각 서버에서 10분마다 실행됩니다. 이 모음은 CPU, 메모리, 네트워크, 디스크 사용률에 관한 데이터를 수집하는 성능 수집 스크립트를 실행합니다.
수집되는 데이터
수집 스크립트는 대상 VM에 대한 데이터를 수집하여 VM의 구성 방식과 사용하는 리소스를 파악합니다. 이를 통해 클라우드로의 마이그레이션을 평가하고 계획하는 데 도움이 됩니다.
다음 목록에는 수집되는 데이터가 설명되어 있습니다.
시스템 정보: VM의 크기, 성능 요구사항, 특정 하드웨어 또는 드라이버에 대한 종속 항목을 결정하는 데 중요한 기본 정보입니다. 포함되는 요소는 다음과 같습니다.
운영체제 (버전 및 출시)
하드웨어 (CPU, 메모리, BIOS 세부정보)
네트워크 구성 (네트워크 인터페이스, IP 주소, 라우팅 테이블)
저장소 (디스크 드라이브, 파티션, 마운트 지점)
설치된 소프트웨어 및 서비스: 스크립트는 설치된 패키지 및 실행 중인 서비스 목록을 수집하여 VM의 소프트웨어 스택과 역할을 파악합니다. 포함되는 요소는 다음과 같습니다.
웹 서버 (Apache, Tomcat, JBoss)
데이터베이스 (SQL Server 증거는 Windows 스크립트에서 수집됨)
이전 중에 특정 구성이 필요할 수 있는 기타 애플리케이션
애플리케이션 구성: 스크립트는 웹 서버 (IIS, Apache, Tomcat, JBoss, Wordpress)의 구성 파일도 수집합니다. 이렇게 하면 이러한 애플리케이션의 특정 설정과 종속 항목을 이해하는 데 도움이 되며, 이는 클라우드 환경으로 원활하게 전환하는 데 매우 중요합니다.
VMWare 및 클라우드 환경 감지: Linux 및 Windows 스크립트 모두 VM이 이미 클라우드 환경 (AWS 또는 Google Cloud)에서 실행 중인지 또는 VCenter 클러스터에서 실행 중인지 감지하려고 시도합니다.
이러한 클라우드 제공업체의 메타데이터 서버에 요청을 보내는 방식으로 이를 실행합니다. VM이 이미 클라우드에 있는 경우 스크립트는 인스턴스 ID, 인스턴스 유형, 기타 세부정보와 같은 관련 메타데이터를 수집합니다.
성능 측정항목: 성능 수집 스크립트는 리소스 사용률을 측정합니다. 여기에는 다음이 포함됩니다.
CPU
메모리
I/O 작업
네트워킹
네트워크 연결: 스크립트는 열린 연결을 수집하여 네트워크 리소스에 대한 다양한 종속 항목의 그림을 만드는 데 도움을 줍니다.
대상 머신에 미치는 성능 영향
리소스 사용률 평가
대상 머신에서 수집 스크립트의 리소스 사용량은 실행 중인 프로세스 수, 배포된 애플리케이션 수, 활성 네트워크 연결 수와 같은 매개변수에 따라 다릅니다.
Windows에서는 컬렉션 스크립트가 스레딩 API를 통해 사용 가능한 가장 낮은 우선순위를 사용하여 실행됩니다.
Linux에서는 nice 값 5가 프로덕션 워크로드와의 간섭을 최소화하고 수집 스크립트보다 우선순위가 높게 설정되도록 하는 데 사용됩니다.
일반적인 수집은 부하가 없는 머신에서 5~20초 동안 높은 단일 코어 CPU 사용량을 사용할 수 있습니다. 다른 워크로드가 있는 경우 이러한 워크로드의 우선순위가 더 높기 때문에 시간이 더 오래 걸릴 수 있습니다.
완화 전략
탐색 클라이언트는 특정 시간에 특정 서버의 수집을 방지하는 메커니즘을 제공합니다. 이 기능을 사용하면 사용량이 많은 시간에 중요한 워크로드를 실행하는 서버에서 수집을 방지할 수 있습니다.
보안 고려사항
인증 및 승인
대상 머신과의 통신
탐색 클라이언트는 보안 채널을 사용하여 대상 머신을 인증하고 통신합니다. 여기에는 SSH, WMI, VMware 도구, VCenter 연결이 포함됩니다.
탐색 클라이언트는 이러한 프로토콜의 일부로 내장된 보안 조치를 사용합니다.
SSH에서 탐색 클라이언트는 사용자 이름-비밀번호 인증과 키 기반 인증을 모두 허용합니다. 지원되는 키 쌍 유형의 전체 목록은 타겟 애셋 요구사항을 참고하세요.
Google Cloud과의 커뮤니케이션
등록된 탐색 클라이언트는 정상적으로 작동하는 동안 Google Cloud Migration Center와 통신합니다. 통신은 roles/migrationcenter.discoveryClient 역할 결합이 있는 서비스 계정을 통해 이루어집니다. 서비스 계정은 자동으로 생성되거나 등록 프로세스 중에 사용자가 제공합니다.
서비스 계정 비공개 키는 다음 섹션에 설명된 암호화 메커니즘을 사용하여 검색 클라이언트 머신에서 암호화됩니다.
Google Cloud 에 대한 모든 통신은 이 서비스 계정을 사용하여 인증되고 SSL/TLS를 사용하여 암호화됩니다.
데이터 암호화
전송 중: 모든 검색 클라이언트 커뮤니케이션 채널은 암호화를 사용하여 전송 중인 데이터를 보호합니다. 여기에는 다양한 프로토콜 (SSH/WMI)을 사용하여 대상 머신과 통신하고 HTTPS를 사용하여 Google Cloud 와 통신하는 것이 포함됩니다.
저장 중: 탐색 클라이언트 PII, SPII, 비밀은 모두 AES128_GCM 알고리즘을 사용하여 저장 중 암호화되며 Windows DPAPI를 사용하여 암호화 키를 안전하게 저장합니다.
침입 감지 및 방지
검색 클라이언트는 조직의 여러 VM에 연결하고 스크립트를 실행하는 데 사용되므로 EDR 또는 xDR 알림을 트리거할 수 있습니다. 이는 보안 도구가 구성된 방식과 사용하는 특정 도구에 따라 크게 달라집니다. 특정 알림 및 기기에 대한 예외를 만들고 고려하세요.
로깅 및 지원 가능성
탐색 클라이언트는 디버깅 및 지원을 위해 작동 중에 로그를 수집합니다. 탐색 클라이언트 로그는 다음 두 가지 메커니즘을 사용하여 수집됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Discovery client data collection and security\n\nThis document addresses concerns and questions about installing the\nMigration Center discovery client in data centers. It emphasizes the\nimportance of security, compliance, and performance when discovering and\ncollecting data from customer IT assets in highly regulated environments.\n\nHow data collection is performed\n--------------------------------\n\nThe discovery client uses several methods to collect data from target\nmachines. The data collected varies depending on the method.\nAt guest level, data is collected using the collection scripts;\nat the hypervisor level, data is collected using the underlying platform APIs.\n\n### Discovery client service and process\n\nThe discovery client runs as a service called `GoogleMCDC` under a process\ncalled `mcdc_service.exe`.\n\n### Collection scripts\n\nAll the guest-level collection methods used by the discovery client run\ncollection scripts on the target machines. You can review the actual scripts\nused for collection at the following links:\n\n- Linux\n - [Full collection](https://storage.googleapis.com/mcdc-release/current/mcdc-linux-collect.sh)\n - [Performance collection](https://storage.googleapis.com/mcdc-release/current/mcdc-linux-collect-performnace.sh)\n- Windows\n - [Full collection](https://storage.googleapis.com/mcdc-release/current/mcdc-windows-collect.ps1)\n - [Performance collection](https://storage.googleapis.com/mcdc-release/current/mcdc-windows-collect-performance.ps1)\n\nThe collection scripts store the results in an archive file (zip or tar)\nwhich the discovery client then retrieves.\n\n### Collection mechanisms\n\nThe discovery client may use one or more of the collection mechanisms\ndescribed in the following sections to collect data from the target machines.\n\n#### SSH (Linux)\n\nDuring SSH collection, the following process occurs:\n\n1. An SSH session is initiated between the collector machine and the target server.\n2. A temporary directory is created under `~/.mcdc-temp/`.\n3. The collection script is copied to that directory.\n4. The collection script is executed.\n5. The result archive is fetched using SCP.\n6. The temporary directory is cleaned up.\n\n#### WMI (Windows)\n\nDuring WMI collection on Windows, the following process occurs:\n\n1. A WMI connection is initiated to the target machine.\n2. A temporary (volatile) registry key is created on the target machine under `HKLM:\\SOFTWARE\\Google\\Collector\\data`.\n3. The collection script is copied to the registry key.\n4. A temporary directory is created under `C:\\temp`.\n5. The collection script is written to the temporary directory.\n6. The collection script is executed.\n7. The result of the collection is written to the volatile registry key.\n8. The result is copied to the collector machine.\n\n#### VMware Guest Tools (Linux and Windows)\n\nDuring VMware collection for both Linux and Windows, the following process\noccurs:\n\n1. A temporary directory is created using VMware guest tools.\n2. The collection script is copied to that directory.\n3. The collection script is executed.\n4. The result archive is fetched using VMware guest tools.\n5. The temporary directory is cleaned up.\n\n### Periodic data collection\n\nThe discovery client collects data from all configured servers in a periodic\nmanner. There are two types of collection:\n\n- **Full collection:** Runs once a day for each server. This collection executes the full collection script that collects various information on the VM such as the hardware, environment, installed software, running processes, and more.\n- **Performance collection:** Runs every 10 minutes on each server. This collection executes the performance collection script that collects data on the CPU, memory, network and disk utilization.\n\nWhat data is collected\n----------------------\n\nThe collection scripts collect data about target VMs to understand how they are\nconfigured and what resources they use. This helps in assessing and planning\ntheir migration to the cloud.\n\nThe following list describes the data that is collected:\n\n- **System information** : The basic information that is crucial for determining the VM's size, performance requirements, and dependencies on specific hardware or drivers. It includes:\n - Operating system (version and release)\n - Hardware (CPU, memory, BIOS details)\n - Network configuration (network interfaces, IP addresses, routing tables)\n - Storage (disk drives, partitions, mount points)\n- **Installed software and services** : The scripts collect a list of installed packages and running services to understand the VM's software stack and its role. It includes:\n - Web servers (Apache, Tomcat, JBoss)\n - Databases (evidence of SQL Server is collected in the Windows script)\n - Other applications that might require specific configurations during migration.\n- **Application configurations**: The scripts also gather configuration files for web servers (IIS, Apache, Tomcat, JBoss, Wordpress). This helps in understanding the specific settings and dependencies of these applications, which is vital for ensuring a smooth transition to the cloud environment.\n- **VMWare and cloud environment detection**: Both the Linux and Windows scripts attempt to detect if the VM is already running in a cloud environment (AWS or Google Cloud), or in a VCenter cluster. They do this by making requests to the metadata servers of these cloud providers. If the VM is already in the cloud, the scripts collect relevant metadata suc as instance ID, instance type, and other details.\n- **Performance metrics:** The performance collection scripts measure resource utilization. This includes the following:\n - CPU\n - Memory\n - I/O operations\n - Networking\n- **Network connections:** The scripts collect open connections to help create a picture of the different dependencies on network resources.\n\nPerformance impact on target machines\n-------------------------------------\n\n### Resource utilization assessment\n\nThe resource utilization of the collection scripts on the target machine\ndepends on parameters such as the number of processes running, the number of\napplications deployed, the number of active network connections, and others.\n\nOn Windows, the collection script runs using the lowest priority available\nthrough the Threading API.\nOn Linux, a `nice` value of 5 is used to minimize interference with production\nworkloads, and ensure that they have higher priority over the collection script.\n\nA typical collection might take 5-20 seconds of high single-core CPU usage\non an unloaded machine. It might take longer if other workloads are present,\nbecause these workloads have higher priority.\n\n### Mitigation strategies\n\nThe discovery client provides a mechanism to prevent collection of specific\nservers during specific hours. This feature can be used to prevent the\ncollection from servers running critical workloads during peak hours.\n\nSecurity considerations\n-----------------------\n\n### Authentication and authorization\n\n#### Communication with target machines\n\n- The discovery client uses secure channels to authenticate and communicate with target machines. This includes SSH, WMI, VMware tools, and VCenter connections. The discovery client uses the built-in security measures as part of these protocols.\n- In SSH, the discovery client allows both username-password and key-based authentication. For a full list of the supported types of key pairs, see [Target asset requirements](/migration-center/docs/target-assets-requirements?version=v6#linux_machines).\n\n#### Communication with Google Cloud\n\n- Registered discovery clients communicate with Google Cloud Migration Center during their normal operation. The communication happens through a service account with the `roles/migrationcenter.discoveryClient` role binding. The service account is either created automatically, or provided by the user during the registration process.\n- The service account private key is encrypted on the discovery client machine using the encryption mechanism described in the following section.\n- All communication to Google Cloud is authenticated using this service account, and encrypted using SSL/TLS.\n\n### Data encryption\n\n- **In transit:** all discovery client communication channels use encryption to protect data in transit. This includes communication with the target machines using the different protocols (SSH/WMI), and communication with Google Cloud using HTTPS.\n- **At rest:** the discovery client PII, SPII and secrets are all encrypted at rest using the `AES128_GCM` algorithm and using the Windows DPAPI to securely store the encryption keys.\n\n### Intrusion detection and prevention\n\nAs discovery client is used to connect and run scripts on many\nVMs in your organization, it may trigger EDR or xDR alerts. This is highly\ndependent on the way your security tools are configured and the specific tools\nyou are using. Be aware and consider creating exemptions for the specific alerts\nand devices.\n\nLogging and supportability\n--------------------------\n\nThe discovery client collects logs during its operation to allow for\ndebugging and support. The discovery client logs are collected using two\nmechanisms:\n\n- **Local logs:** The logs are written to file under `C:\\ProgramData\\Google\\mcdc\\logs`. The log files are rotated and compressed.\n- **Cloud logs:** Registered clients also send the logs to Google Cloud so they can be used by the Google Cloud support team when customer issues are reported."]]
