Mac에서 trustd란 무엇인가요? 인증서 신뢰 데몬에 대한 설명

trustd는 macOS에 내장된 인증서 신뢰 평가 데몬입니다. 이 시스템 프로세스는 Apple이 배포하고 코드 서명한 것으로, Mac이 연결하는 서버가 제공하는 디지털 인증서를 신뢰할지 여부를 결정하는 역할을 합니다.

Mac에서 HTTPS 또는 TLS 연결이 이루어질 때마다 서버는 인증서 체인을 제시합니다: 자체 인증서, 보통 하나 이상의 중간 인증서, 그리고 궁극적으로 시스템이 이미 신뢰하는 루트 인증서입니다. 누군가는 그 체인을 검사해야 합니다. 그 역할을 하는 것이 바로 trustd입니다. trustd는 인증서가 유효하게 서명되었는지, 만료되었는지, 폐기되었는지, 그리고 체인이 Mac이 진정으로 신뢰하는 루트에서 끝나는지 평가합니다.

이 작업은 앱별로 수행되지 않습니다. 대신, 모든 브라우저, 메일 클라이언트, 업데이트 프로그램, Electron 앱이 자체 인증서 논리를 구현하고 미묘하게 잘못하는 대신, macOS는 신뢰 평가를 하나의 시스템 서비스에 중앙집중화합니다. 그래서 trustd가 바쁘게 보이는 것입니다: 사실상 모든 네트워크 기능이 있는 프로세스를 대신하여 작업하기 때문입니다. Safari의 페이지 로드, 메일 확인, 파일 동기화, 백그라운드 업데이트 모두 같은 순간에 신뢰 평가를 유발할 수 있습니다.

보통 trustd는 시스템 수준 프로세스로 실행되는 것을 볼 수 있으며, 때때로 사용자별 인스턴스와 함께 실행됩니다. 둘 다 정상입니다. 이것은 사용자가 설치한 것이 아니며, 의미 있게 제거할 수 있는 것도 아닙니다.

이 부분이 사람들을 놀라게 하므로, 명확히 설명하는 것이 좋습니다. 인증서가 유효하게 서명되었는지 확인하는 것은 오프라인에서도 수학적 계산만으로 가능하지만, 지금 바로 유효한지 확인하는 것은 불가능합니다.

인증서는 폐기될 수 있습니다. 서버의 개인 키가 도난당하거나, 인증서 기관이 실수로 인증서를 발급하거나, 회사가 도메인에 대한 통제권을 잃는 경우가 있습니다. 이 경우 인증서는 여전히 암호학적으로 올바르게 형성되어 있고, 유효 기간 내에 있지만 더 이상 신뢰해서는 안 됩니다. Mac이 이를 알 수 있는 유일한 방법은 다른 곳에 게시된 데이터를 참조하는 것인데, 이는 네트워크 요청을 의미합니다.

그래서 trustd는 인증서 폐기 및 유효성 정보를 위해 Apple 인프라에 접속합니다. 이는 OCSP 스타일 상태 확인, Apple의 자체 검증 서비스, 그리고 발급되었지만 절대 그래서는 안 되었던 인증서를 감지하는 데 사용되는 인증서 투명성 관련 데이터 등을 포함합니다. trustd가 Apple 도메인에 반복적으로 접속하는 것을 보면, 그것이 바로 그 연결입니다. 이는 보안 조회이지, 사용자에 대한 보고가 아닙니다.

Apple은 또한 이 데이터를 캐시하므로, 패턴이 일관적이지 않고 브라우징과 비례하지 않는 bursty한 형태를 띱니다. 재부팅 후, 오랜 유휴 기간 후, 또는 최근 방문하지 않은 사이트를 방문할 때 연결이 집중될 수 있으며, 그 외에는 비교적 적게 발생합니다. 이 신뢰 및 검증 스택은 서명되고 공증된 소프트웨어를 검사하는 데에도 사용되며, 그 구체적인 작동 방식은 Apple이 문서화합니다.

아니요. trustd는 Apple의 1st-party 시스템 데몬이며, macOS 보안의 문서화된 일부입니다. 건강한 Mac에는 그것이 없는 버전이 없습니다.

즉, 기사에 의존하는 것은 맬웨어가 하는 방식과 정확히 일치하므로, 자신의 기기에서 직접 확인하는 것이 합리적입니다. 확인할 만한 두 가지가 있으며, 특별한 도구가 필요하지 않습니다.

첫 번째는 위치입니다. Apple의 시스템 데몬은 보호된 시스템 경로 내에 존재하며, trustd의 실행 파일은 시스템의 usr/libexec 영역에 있습니다. 현대 macOS에서는 이 경로가 읽기 전용 서명된 시스템 볼륨에 있으며, 맬웨어가 쓸 수 없습니다. Activity Monitor에서 프로세스를 선택하고 검사기를 열어 보고된 경로를 확인하세요. 홈 폴더, 다운로드 디렉터리 또는 낯선 앱 번들에서 실행되는 trustd는 의심스러운 신호입니다. 시스템 볼륨에서 실행된다면, 그것이 진짜입니다.

두 번째는 서명입니다. macOS는 실행 중인 바이너리의 서명자를 알려줄 수 있으며, Apple의 데몬은 시스템 권한으로 Apple이 서명합니다. 올바른 경로와 Apple 서명이 함께 있으면 운영 체제의 일부임을 의미합니다. 또한 프로세스 이름을 자세히 읽는 것도 도움이 되며, 가짜는 대개 비슷하지만 정확히 일치하지 않는 이름을 선택하기 때문입니다.

추가로 안심할 수 있는 점은, trustd의 높은 CPU 사용량이나 지속적인 네트워크 활동이 침해의 증거는 아니라는 것입니다. 이는 많은 TLS 연결이 평가되고 있다는 의미이며, 정상적인 Mac에서는 자연스러운 현상입니다.

기술적으로 방화벽으로 trustd를 차단할 수 있어. 하지만 그렇게 하지 말아야 해. 사람들이 조용히 하도록 유혹받는 백그라운드 macOS 프로세스 중에서, 이것은 차단하면 오히려 Mac이 더 안전하지 않고 프라이버시도 덜 보호되는 몇 안 되는 경우 중 하나야.

인증서 검증은 핵심 보안 통제 수단이야. 이 메커니즘은 Mac이 폐기된 인증서나 신뢰할 수 없는 체인에 대해 조용히 수락하는 것을 막아줘. 이를 저하시키면, 서버와의 암호화된 연결이 실제로 그 서버와 연결된 것인지 보장하는 것도 저하돼.

실질적인 결과는 빠르게 나타나: HTTPS 연결이 바로 실패하거나, 검증 조회를 기다리느라 멈추거나, 관련 없는 앱에서 모호한 인증서 오류가 발생하거나, 로그인 흐름이 멈추는 것. trustd가 거의 모든 것 아래에 있기 때문에, 증상은 원인으로 바로 연결되지 않는 경우가 많아. 너는 여러 군데서 Mac이 고장 난 것처럼 느껴지지만, 명백한 경고는 아니야.

정직한 프라이버시 관점에서 보면, 폐기와 유효성 검증은 본질적으로 검증을 수행하는 서비스에 어떤 인증서가 특정 시점에 검증되었음을 알려줘. 이것은 이 메커니즘 계층의 실제 특성이지, 숨겨진 것이 아니야. Apple은 이 트래픽 처리 방법에 대한 정보를 공개했고, 그 문서가 구체적인 내용을 알 수 있는 올바른 출처야. 또한, macOS에서 인증서와 공증 관련 검증이 몇 년 전 Apple 서비스 문제로 인해 앱 실행 시 눈에 띄는 느려짐을 일으켰을 때, Apple이 이 검증 방식의 일부를 변경한 것도 주목할 만해. 핵심은 이 메커니즘이 사악하거나 음흉한 것이 아니라, 부하를 견디는 부분이어서 모두가 그 작동에 신경을 쓰게 된다는 점이야.

그러니 네 기기를 이해하려면 trustd를 모니터링해. 차단하지 말아라.

trustd가 만들어내는 불안감은 거의 trustd와 관련이 없어. 그것은 원시 연결 로그가 거의 읽기 어려운 상태라는 거야. 네가 시작하지 않은 프로세스가 네가 모르는 도메인에 접속하는 것, 그 빈도수도 설명할 수 없는 것, 이 설명은 인증서 검증, 크래시 보고, 업데이트 체크, 분석 SDK와도 똑같이 맞아.

그래서 사람들은 모든 것을 무시하거나, 본능적으로 차단하는데, 이게 바로 기계들이 수수께끼 같은 HTTPS 실패를 겪게 되는 원인이지. 둘 다 같은 빠진 조각에서 비롯돼: 어떤 프로세스가 말하는지, 어디로 가는지, 그 목적지가 알려진 인프라인지 아니면 알려진 추적기인지에 대한 맥락.

이 맥락이 바로 NetMute이 제공하는 것이야. 실시간으로 앱별, 프로세스별 트래픽을 보여줘서, 연결이 익명 대신 trustd에 귀속되도록 해줘. 도메인 수준의 로그는 어떤 도메인에 프로세스가 접속했는지, 언제, 얼마나 많은 데이터가 이동했는지 기록해서 "무언가가 Apple과 통신한다"는 것을 검증 가능한 기록으로 만들어줘. Tracker Shield는 1,100개 이상의 알려진 추적기 도메인 목록을 분류해서 보여주기 때문에, 진짜 추적은 일반 시스템 트래픽과 구별할 수 있어. 그리고, 말하지 말아야 할 것이 통신하는 것을 발견하면, 앱별 방화벽이 원클릭 차단과 임시 규칙 만료 기능을 제공해서, 차단이 문제를 일으키는지 먼저 테스트할 수 있게 해줘.

이 작업 흐름은 간단해. trustd를 보고, Apple 검증 인프라에 접속하는지 확인하고, 추적기 목록에 없는지 확인한 후, 그냥 두면 돼. 그리고 같은 뷰를 실제 질문이 있었던 앱으로 돌려봐, 왜냐하면 그것은 거의 시스템 데몬이 아니기 때문이야.