English · 한국어
자주 묻는 질문¶
보안팀, 운영팀, 관리자가 pqcota를 실제 시스템 가까이에 두기 전에 흔히 묻는 질문입니다. 답마다 pqcota가 무엇을 하고 어디서 멈추는지 밝힙니다. 전체 개요는 README에서 시작하세요. 결과를 보고서에 쓰는 방법은 보고 안내, 빌드와 실행은 빌드 안내를 보세요.
시작하기 전에¶
관측하려는 시스템에 무엇을 설치해야 하나요? 상주 에이전트도 서비스도 없습니다. 제공되는 Ansible 플레이북이 시스템마다 관측 프로그램을 임시 디렉터리에 복사해 실행하고, 결과를 가져온 뒤 그 디렉터리를 지웁니다. 일부 관측에는 전제가 있고, Java 관측은 그 디렉터리 밖에도 파일 하나를 씁니다. 다음 질문들을 보세요. 시스템 하나를 직접 관측한다면 그 시스템에서 프로그램 하나를 실행할 뿐 다른 것은 필요 없습니다.
관측 프로그램에는 어떤 권한이 필요한가요? 권한이 적을수록 시야가 좁아집니다. 그것이 어떻게 드러나는지는 프로그램과 실패의 종류에 따라 다릅니다. 갭 기록일 수도 있고, 프로그램 통계의 집계일 수도 있고, 실행 로그의 메시지뿐일 수도 있습니다. 어느 쪽인지는 보고 안내에 있습니다.
| 프로그램 | 권한 | 없으면 |
|---|---|---|
pqcota-nodescan(OpenSSL) |
자기 프로세스는 그대로 동작합니다. 다른 사용자의 프로세스를 보려면 root나 CAP_SYS_PTRACE가 필요합니다 |
보이는 프로세스가 줄고, 거부된 것은 통계에 집계됩니다. 프로세스 목록을 전혀 읽지 못하면 결과에 그렇게 적습니다 |
pqcota-netcap(연결) |
CAP_NET_RAW(또는 root) |
캡처하지 않고, 권한을 부여하는 방법을 출력하고, 갭 기록을 씁니다 |
pqcota-jvmscan(Java) |
대상 JVM과 같은 사용자 또는 root | JVM이 attach를 막으면 정적 설정을 읽는 방식으로 돌아가며, 실행 중에 등록된 provider는 보이지 않습니다 |
pqcota-cngscan(Windows) |
특별한 권한 없음 |
Windows에서는 다른 사용자가 실행한 Java 프로세스를 관리자 계정으로 접속했을 때만 볼 수 있습니다.
어떤 시스템을 지원하나요? 지원 범위를 보세요. 요약하면, Linux의 OpenSSL과 Java, 관측만 하는 Windows CNG, 그리고 Linux 대상에만 변경을 생성합니다. Linux 대상은 커널 3.2 이상이 필요한데 이는 Go 자체의 하한입니다. 개별 기능이 그 밖에 필요로 하는 것은 명령 참조(영문)에 있습니다.
중앙 쪽에는 무엇이 필요한가요? 컨트롤러 프로그램이 있는 머신, 여러 시스템을 관측한다면 Ansible과 대상으로의 SSH 접근, 시스템과 시간에 걸친 이력과 비교를 원하면 Postgres가 필요합니다. 시스템 하나를 보려면 어느 것도 필요 없습니다.
인터넷 접근이 필요한가요? 설치와 빌드에는 필요합니다(소스 코드, 의존성). 데모를 돌릴 때는 컨테이너 이미지를 내려받습니다. 평소에 pqcota는 SSH(Windows는 WinRM)로 사용자의 시스템에 접속하고, 사용자가 지정한 데이터베이스나 파일에 씁니다. pqcota 프로그램에는 내장된 업로드나 원격 측정 경로가 없습니다. 이것은 트래픽을 측정한 결과가 아니라 소스에서 네트워크 클라이언트 코드를 찾아본 결과입니다. 정책이 증명을 요구한다면 트래픽을 직접 지켜보세요.
실행 중인 시스템에 미치는 영향¶
관측이 운영 환경을 방해할 수 있나요? 관측에 따라 다르며, 관측마다 건드리는 것이 다릅니다.
| 관측 | 시스템에서 하는 일 |
|---|---|
OpenSSL(pqcota-nodescan) |
/proc으로 프로세스 목록과 로드된 라이브러리를 읽고, 라이브러리 파일을 읽어 버전을 찾습니다. 프로세스에 attach하지 않고 다른 도구를 실행하지 않습니다 |
연결(pqcota-netcap) |
원시 패킷 소켓을 열고 짧은 구간(기본 8초) 동안 네트워크 인터페이스의 프레임을 메모리로 받은 뒤, TLS와 SSH 핸드셰이크에서 협상 정보를 뽑습니다. 핸드셰이크만 받도록 제한되어 있지는 않습니다. 트래픽을 복호화하지 않으며 원시 패킷 캡처를 파일로 쓰지 않습니다 |
Java(pqcota-jvmscan) |
수동적이지 않습니다. 실행 중인 JVM의 provider 목록을 읽으려고 그 JVM에 attach해 작은 에이전트를 올립니다. 에이전트는 등록된 보안 provider를 나열해 대상의 /tmp에 파일(pqcota-providers-<pid>.txt)로 쓰며, provider를 바꾸지는 않습니다 |
기능 보고는 세 가지 모두 invasive: false로 적습니다. 그와 별개로 Java 단계는 JVM의 attach 방식을 써서 대상 JVM 안에서 코드를 실행하고 결과 파일을 /tmp에 남기므로, 그것이 정책에 맞는지 판단하세요. 관측하지 않고 먼저 살펴볼 수도 있습니다. pqcota-jvmscan --recon은 찾은 JVM을 나열하고, --pid는 관측을 JVM 하나로 제한합니다. pqcota-jvmscan이 어느 경로를 택하는지는 사용자가 무엇을 주는지에 달려 있습니다. 에이전트 파일(PQCOTA_JVM_AGENT)이 있고 JVM을 하나 이상 찾았으면 attach합니다. 에이전트 파일이 없어도 --pid가 있으면 그 JVM의 정적 설정을 읽으며 실행 중의 등록은 볼 수 없습니다. 에이전트 파일도 --pid도 없으면 JVM이 돌고 있어도 자체 Java 런처를 시작해 기본 provider 체인을 읽고, 결과를 실행 중인 애플리케이션의 관측이 아니라 관측 범위가 제한된 대체 결과(degraded)로 기록합니다. 시작하려면 그 머신에 Java 런타임이 있어야 합니다. 결과의 메모가 탐색을 실행한 까닭을 알려 주므로(JVM을 찾았지만 에이전트가 없음, 프로세스 목록을 읽을 수 없음, 실행 중인 JVM이 없음) 결과를 믿기 전에 읽으세요.
실행이 실패하거나 중단되면 어떻게 되나요?
플레이북의 정리는 성공한 실행의 마지막 단계로 자신의 임시 디렉터리를 지웁니다. 실패나 중단 뒤에는 그 디렉터리가 남을 수 있으니 확인하세요. 성공한 실행도 모든 것을 지우지는 않습니다. Java attach 경로는 플레이북이 지우는 디렉터리 밖인 대상의 /tmp에 pqcota-providers-<pid>.txt를 쓰고, 수집기는 그 파일을 읽지만 지우지 않습니다. JDK 클라이언트를 쓰는 대체 경로는 자신의 파일을 지웁니다. 중요하다면 대상의 /tmp를 확인하세요. 실행되지 않은 수집기는 인벤토리에 갭 기록을 남기지 않으니, 실행 로그를 관측하려던 시스템 목록과 대조하세요.
pqcota가 스스로 시스템을 바꾸나요? 양자내성 변경을 적용하지 않습니다. 그것은 파일로 생성되고 사용자가 자신의 도구로 적용합니다. 다만 관측에 부작용이 없는 것은 아닙니다. Java 단계는 대상 JVM 안에서 코드를 실행하고 파일을 남기며, 연결 캡처는 원시 패킷 소켓을 씁니다.
데이터¶
무엇을 수집하나요? 시스템마다 로드된 암호 라이브러리와 그 버전, 등록된 Java 보안 provider, 그리고 지켜본 연결의 상대 주소와 포트, 프로토콜, 협상된 키 교환 그룹과 암호화 방식(cipher)입니다. 이는 사용자 인프라에 관한 정보이므로 그에 맞게 다뤄야 합니다.
우리의 트래픽, 비밀번호, 키를 읽나요? 연결 캡처는 프레임을 메모리로 받아 핸드셰이크에서 협상된 알고리즘 이름과 상대 주소를 뽑습니다. 이 캡처 경로는 트래픽을 복호화하지 않고 원시 패킷 캡처 파일을 쓰지 않습니다. 실행 중에 내용이 메모리에 전혀 있지 않다고 약속하지는 않습니다. 인벤토리에는 로그인이나 키를 담는 필드가 없습니다. 접속 정보를 담는 Ansible 대상 목록은 실행할 때 만들어 소유자만 읽게 하며 인벤토리에 저장하지 않습니다. pqcota는 키 자료를 읽도록 설계되지 않았지만, 이 문서는 그것을 위해 모든 코드 경로를 감사했다고 주장하지 않습니다.
데이터는 어디에 저장되고 누가 읽을 수 있나요? 사용자가 고른 Postgres 데이터베이스와 파일에 저장됩니다. 데이터베이스를 설정하지 않으면 그 실행의 인벤토리 이력은 메모리에만 있다가 프로그램이 끝나면 사라집니다. 수집기가 만든 결과 파일, 저장해 둔 출력, 실행 로그는 그 영향을 받지 않으며 따로 보관과 삭제 정책이 필요합니다. 누가 무엇을 읽을 수 있는지는 그 데이터베이스와 파일의 접근 통제가 정합니다. 여러 조직이 하나의 데이터베이스를 쓴다면 기록이 섞이지 않도록 조직 식별자를 지정하세요. 기록이 한번 섞이면 나눌 수 없습니다.
결과에 서명하나요? 선택 사항입니다. 수집기에 개인 키를 주면 결과에 서명하고, 적재하는 쪽에 짝이 되는 공개 키가 있으면 서명을 확인해 맞지 않는 것을 거부합니다. 키를 설정하지 않으면 검증을 건너뛰고, 적재 요약은 그 결과들을 검증한 것과 따로 검증하지 않음으로 셉니다. 키 없이는 적재가 시작되지 않도록 검증을 필수로 요구할 수 있습니다.
네트워크 밖으로 나가는 것이 있나요? 위의 「인터넷 접근이 필요한가요?」를 보세요. 내장된 업로드 경로는 없습니다. 결과를 이후에 어떻게 쓰는지는 사용자에게 달려 있습니다.
결과 읽기¶
🔴는 무슨 뜻인가요? pqcota가 지켜보는 동안 그 연결에서 고전 알고리즘이 협상됐다는 뜻입니다. 취약하다거나 규정을 어겼다는 판정이 아니며, pqcota는 위험을 점수로 매기지 않습니다. 결과 읽는 법을 보세요.
「confirmed」는 무슨 뜻인가요? 증거의 강도이며, 그 사실을 어떻게 수집했는지로 정해집니다. 실행 중인 시스템에서, 소스에서, 또는 추적으로 본 사실은 「confirmed」입니다. 제공받은 암호 자산 명세서에서 가져온 사실은 아무도 실행 중인 시스템을 관측하지 않았으므로 더 낮게 매깁니다.
왜 결과에 시스템이 빠져 있나요? 가능한 까닭이 여럿이고, pqcota는 그중 일부만 기록합니다. 등록 목록에 없을 수 있고, 수집기가 그 운영체제를 지원하지 않을 수 있고, 필요한 권한이 없을 수 있고(갭으로 기록됨), 수집기가 아예 실행되지 않았을 수 있습니다(아무것도 기록되지 않음). 전체 표는 보고 안내에 있습니다.
변경을 적용했는데 왜 인벤토리가 바뀌지 않았나요? OpenSSL은 pqcota가 라이브러리와 그 버전을 관측하고 어떤 provider가 로드됐는지는 관측하지 않으므로, provider를 추가해도 그 자체로는 나타나지 않습니다. 프로젝트 자체 데모에서 시험 노드의 사용 가능한 ML-KEM 알고리즘 수는 provider를 적용한 뒤 0에서 14가 되고 되돌린 뒤 다시 0이 됐지만, 다시 관측해도 변화가 없었습니다. 연결의 등급도 양쪽이 새 알고리즘을 지원할 때만 바뀝니다. 변경 확인과 그 한계를 보세요.
연결 옆의 @?는 무슨 뜻인가요?
그 연결을 연 애플리케이션을 식별하지 못했다는 뜻이며, 대개 조회하기 전에 연결이 닫혔기 때문입니다. pqcota-declare-attribution으로 사람이 채울 수 있습니다. 그렇게 채운 값은 선언한 것으로 표시되며 관측과 섞이지 않습니다.
변경¶
pqcota가 대신 변경을 적용할 수 있나요? 아니요. 표준 Ansible 파일을 생성하고, 사용자가 실행합니다. 원격 실행 엔진이 없으므로 변경이 적용됐는지와 언제 적용됐는지는 pqcota가 아니라 사용자의 배포 도구가 기록합니다.
변경을 되돌릴 수 있나요? 생성한 변경마다 짝이 되는 제거 파일이 있습니다. 변경은 기존 파일을 덮어쓰지 않고 파일을 더하므로 제거는 더한 것을 지웁니다. 계획에 활성화 단계가 있으면 제거가 먼저 그 비활성화 단계를 실행합니다. 이것은 이전 배포를 복원하는 것이 아닙니다. 같은 경로에 두 번 배포했다면 제거는 파일을 지울 뿐 앞선 버전을 되살리지 않습니다. 설정으로 구현할 수 없는 변경은 수동 단계로 표시되며 되돌리는 것도 수동 단계입니다.
누가 변경을 승인하고, 그것은 어떻게 확인하나요?
생성하려면 승인 서명이 붙은 확정된 계획이 필요합니다. 기본적으로 생성기는 서명을 승인자의 등록된 공개 키로 확인하고, 확인하지 못하면 거부합니다. 별도의 옵션 둘이 이를 완화합니다. --allow-unverified-approvals는 등록된 승인자 키가 없을 때(PQCOTA_APPROVAL_KEYS가 비었을 때) 검증 없이 생성을 계속하게 합니다. 등록된 키로 확인해 맞지 않는 서명까지 통과시키지는 않습니다. --allow-incomplete는 빈칸이 있는 출력도 종료 코드 0으로 끝나게 하며, 서명 검증을 건너뛰지는 않습니다. 각각 선택한 것이라는 경고를 출력하며, 그것을 보고하는 방법은 보고 안내에 있습니다. 조직의 검토 절차와 승인자 키의 보관은 pqcota 밖의 일입니다.
OpenSSL 1.1.1이나 오래된 JDK를 쓰면 어떻게 되나요? 그런 시스템에는 아무것도 생성하지 않습니다. 설정으로는 거기에 양자내성 알고리즘을 더할 수 없기 때문입니다. 출력은 그 변경을 수동 단계(라이브러리 교체나 JDK 업그레이드)로 표시합니다. 전체 표는 지원 범위를 보세요.
Windows용 변경도 생성하나요? 아직 아닙니다. Windows 시스템은 관측할 수 있습니다. 그 변경의 생성은 로드맵(영문)에 있습니다.
OpenSSL, Java, Windows CNG 말고 다른 런타임도 다루나요? 그 셋이 관측하는 대상입니다. 다른 런타임은 따로 하나의 범주로 관측하지 않습니다.
pqcota를 둘러싼 질문¶
pqcota가 규정 준수 도구인가요? 「양자 안전」한 시스템이 몇 개인지 알려 주나요? 아니요. 증거로서 관측, 비교, 생성한 파일을 제공할 뿐 규정 준수나 양자내성을 인증하지 않습니다. 시스템이 아니라 관측한 연결에 등급을 매기며 위험을 점수로 매기지 않습니다. pqcota 결과가 뒷받침하지 않는 문장을 보세요.
얼마나 자주 실행해야 하나요? 관측은 살펴보는 그 시점에 쓰이는 것을 보여 주므로, 시간에 걸쳐 되풀이해야 이력이 쓸모 있어집니다. pqcota는 실행 일정을 짜지 않습니다. 이미 쓰는 스케줄러를 쓰세요.
소스 코드나 컨테이너 이미지를 스캔하나요? 소스 코드는 스캔하지 않습니다. 빌드 파이프라인이 암호 자산 명세서(CycloneDX)를 만든다면 pqcota가 그것을 받아 같은 인벤토리에 넣고, 위에서 설명한 더 낮은 증거 강도로 표시합니다. pqcota에는 컨테이너 이미지를 스캔하는 기능이 없습니다.
얼마나 성숙했나요?
1.0 이전입니다(현재 릴리스 v0.10.6). 계약 변경은 추가만 하는 방식으로 유지됩니다. 호환성 정책을 보세요. 보안 수정은 main과 최신 릴리스에만 반영됩니다. SECURITY를 보세요.
비용은 얼마이고 라이선스는 무엇인가요? Apache-2.0 오픈소스입니다. LICENSE와 라이선스 안내를 보세요.
문제를 신고하거나 질문하려면 어디로 가나요? 버그, 질문, 제안은 리포의 이슈로 보냅니다. 취약점은 SECURITY의 안내대로 비공개로 신고하세요.