LabHub

폐쇄망 현장 — 방산·국방 도메인 · 반입 번들과 무결성 · 퀴즈

퀴즈: 반입 번들과 무결성

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. 번들 전체의 해시 하나만으로 무결성을 확인하는 방식의 가장 큰 한계는?

    1. 해시 계산에 시간이 오래 걸려 대용량 번들에서 실용적이지 않다
    2. 무언가 다르다는 것까지만 알려 주고 어느 파일이 다른지 모르면 조사할 곳이 번들 전체가 된다
    3. 압축 형식이 바뀌면 같은 내용이라도 해시가 달라진다
    4. 받는 쪽이 압축을 풀기 전에는 확인할 수 없어 순서가 꼬인다
  2. 받는 쪽이 서명 검증보다 파일별 해시 대조를 먼저 하면 무슨 일이 생기는가?

    1. 파일 수가 많을 때 검증 시간이 두 배로 늘어난다
    2. 해시 대조 결과가 캐시되어 서명 검증이 건너뛰어진다
    3. 매니페스트의 상대 경로가 해석되지 않아 대조 자체가 실패한다
    4. 아직 진위가 확인되지 않은 매니페스트를 기준으로 대조하게 되어, 목록까지 고친 변조가 전부 통과한다
  3. 공개키를 번들 안에 함께 넣어 보내면 왜 위험한가?

    1. 번들을 쥔 사람이 자기 키쌍으로 페이로드·매니페스트·서명·공개키를 한꺼번에 바꿔도 검증이 통과하기 때문에
    2. 번들 크기가 커져 매체 반입 한도를 넘길 수 있어서
    3. 공개키가 번들 안에 있으면 개인키를 역산할 수 있기 때문에
    4. 받는 쪽이 공개키를 신뢰 저장소에 등록하지 못해 검증 명령이 실패하기 때문에
  4. 받은 번들에서 파일 해시는 전부 일치하는데 서명 검증만 실패했다. 가장 그럴듯한 해석은?

    1. 전송 중 손상이므로 다시 받아 보면 대개 해결된다
    2. 매니페스트 자체가 바뀐 것이므로 다시 받는 것으로 끝날 문제가 아니다
    3. 받는 쪽 openssl 버전이 달라 서명 알고리즘이 호환되지 않는 경우다
    4. 매니페스트에 적힌 경로가 절대 경로여서 대조 기준이 어긋난 경우다
  5. 반입 번들에서 바이너리 파일이 바뀌었는지 확인할 때 쓰면 안 되는 방법은?

    1. file 로 형식이 그대로인지 본다
    2. sha256sum 으로 지문을 대조한다
    3. head 나 grep 으로 앞부분을 열어 눈으로 비교한다
    4. openssl 로 서명된 매니페스트를 통해 간접 확인한다
  6. 폐쇄망 반입에서 '빠진 의존성 하나' 의 비용이 특히 큰 이유는?

    1. 설치 스크립트가 중간에 멈추면 롤백이 불가능하기 때문에
    2. 의존성 하나가 빠지면 매니페스트 해시가 전부 어긋나기 때문에
    3. 빠진 의존성은 서명 검증 단계에서 잡히지 않고 설치 후에야 드러나기 때문에
    4. 안에서는 채울 방법이 없어 다시 나가서 담고 다시 심사를 받아야 하고, 심사 주기가 주 단위인 곳도 있기 때문에