보안 요구·위협모델·보안 아키텍처

공유 버튼을 지웠는데도 문서를 내려받을 수 있다면

외부 감사자에게 보고서를 30분 동안만 보여 주기로 했다. 화면에서는 시간이 지나자 공유 버튼이 사라졌다. 그런데 이전에 복사한 다운로드 주소는 계속 작동한다. 기획자는 만료를 요구했고 개발자는 버튼을 지웠지만, 보호할 결과와 실제 집행 위치가 연결되지 않은 것이다.

이 절에서는 가상의 한시 문서 공유 기능을 끝까지 설계한다. 누가 무엇을 언제 읽을 수 있어야 하는지 정하고, 그것을 어기는 경로를 찾고, 서버의 허용·거부 조건과 시험으로 바꾼다. 사례의 시간·문서·계정·결과는 자체 교육용이며 실제 조직의 운영 성과나 보안 인증이 아니다.

앞의 경계를 실제 설계에 적용하기

신뢰경계는 서로 다른 신뢰수준 사이에서 검증과 통제가 필요한 경계다. 사용자가 보낸 문서번호와 서버 원장의 권한 정보는 같은 신뢰 수준이 아니므로 요청값만으로 허용하지 않는다. 이제 어느 경계에서 어떤 조건을 확인할지를 요구와 시험으로 연결한다.

1. 보안은 출시 직전의 검사 한 번이 아니다

보안엔지니어링은 보호할 자산과 보안 요구를 정하고, 위협모델로 공격·실패 경로를 분석해 보안 아키텍처와 통제를 설계·구현·검증하며, 운영 변화와 사고를 다음 개선에 반영하는 생명주기 활동이다. 데브섹옵스(DevSecOps)는 개발·운영 흐름에 보안 책임과 자동·수동 검증을 지속적으로 통합하려는 실천방식이지 도구 하나의 이름이 아니다.

공유 사례에서 보호할 자산은 보고서 내용과 공유 권한 원장이다. 잘못 읽은 사람이 생기는 피해뿐 아니라 정당한 감사자가 필요한 시간에 읽지 못하는 영향도 함께 본다. “암호화를 적용한다”는 선택만 적으면 누구의 문서인지, 만료 뒤 무엇을 막는지와 같은 업무 조건이 빠진다. 요구의 실패를 관측할 수 있는 형태로 바꾸어야 한다.

원하는 결과를 시험할 수 있는 문장으로 쓰기

보안 요구사항은 보호할 자산·주체·행위와 적용 조건 및 확인 가능한 보안 결과를 명시한 요구다. “안전하게 공유한다”는 문장에 수신자, 대상 버전, 기간과 거부 결과를 넣으면 실제 시험을 만들 수 있다.

나쁜 예는 “링크를 복잡하게 만들고 만료 기능을 구현한다”이다. 좋은 예는 “서버는 지정 감사자가 유효한 공유 권한으로 지정 문서 버전을 읽는 경우만 제공하고, 다른 주체·다른 버전·만료·회수 뒤의 신규 요청에서는 문서 바이트를 제공하지 않는다”이다. 식별자를 추측하기 어렵게 하는 선택은 요청 권한 검사와 별개다. 세부 구현을 요구의 목적처럼 굳히기 전에 다른 구현으로 같은 보호 결과를 얻을 수 있는지도 비교한다.

2. 위협모델은 공격 이름의 목록이 아니다

위협모델은 시스템의 자산·주체·흐름·신뢰 가정에 연결하여 무엇이 잘못될 수 있는지와 대응·검증을 표현한 모델이다. STRIDE는 신원 위장·변조·행위 부인·정보 노출·서비스 거부·권한 상승이라는 여섯 관점에서 위협을 질문하는 분류 틀이다. OWASP는 시스템 이해, 위협 식별, 대응과 검증을 연결하고 설계가 바뀌면 위협모델도 다시 검토하도록 설명한다.[SE-C01]

우리 사례에는 다음처럼 질문한다. 표는 자체 적용이며 원문 그림이나 사례를 복사하지 않았다.

여섯 이름을 모두 썼다고 모든 위협을 발견한 것은 아니다. 분류 개수를 확률이나 위험점수로 바꾸지도 않는다. 공격자가 가진 권한, 필요한 조건, 영향을 받는 자산, 반증할 시험을 붙여야 행동할 수 있는 모델이 된다.

공유를 만드는 경로와 읽는 경로

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

문서 책임자는 공유할 수 있는 범위만 승인한다. 공유 서비스는 수신자·문서·버전·기간을 서버 원장에 기록하며 승인되지 않은 버전을 임의로 발급하지 않는다. 다음 그림의 신규 읽기 판정은 이 현재 원장을 사용한다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

외부 감사자는 서버 원장을 직접 고치지 못한다. 인증된 요청에도 주체·문서·버전·읽기·기간·회수 조건을 모두 대조한다. 불일치 또는 필요한 근거 부재이면 거부·보류하여 미제공하고, 허용일 때만 지정 버전의 검증된 바이트를 제공한다. 제공과 미제공의 실제 결과를 별도 보호된 기록에 연결한다.

공유·회수·판정·실제 제공 기록은 별도 보호된 기록 경로로 전달한다.

사용자 단말, 공유 서비스, 권한 원장과 문서 저장소 사이마다 입력을 신뢰하는 근거와 허용 연산이 다르다. 감사자는 원장을 직접 수정하지 못하고 공유 서비스도 승인되지 않은 문서 버전을 발급하지 못하게 한다. 보안 아키텍처는 이 검증·집행·기록의 책임과 연결을 결정하는 것이지 네트워크 상자를 늘리는 일이 아니다.

3. 실제 정책 SE-G1을 확정한다

가상의 권한 G1은 인증된 감사자 U7에게 문서 D7의 버전 4를 읽게 한다. 시각은 같은 날의 신뢰 가능한 UTC이고 유효구간은 10:00:00 이상 10:30:00 미만이다. 발급자는 해당 문서의 공유 권한을 가진 내부 책임자이고, 수신자는 재공유·변경 권한을 받지 않는다. 문서번호·버전·수신자·행위·기간은 서버가 승인하여 원장에 기록한 값을 기준으로 한다.

서버는 신규 다운로드 요청마다 유효한 인증 주체, 현재 원장, 지정 문서의 불변 버전과 읽기 행위, 기간 및 회수 여부를 모두 확인한다. 한 조건이라도 불일치하면 거부하며 필요한 근거가 확인되지 않으면 보류하고 문서를 제공하지 않는다. 주소만 가지고 있다는 사실이나 과거의 허용 결과로 현재 검사를 대신하지 않는다.

회수가 10:12:00에 원장에 확정되었다면 그 뒤 현재 원장을 읽는 신규 요청을 거부한다. 이미 인가되어 전송 중인 요청은 별도의 종료 정책이 필요한 잔여 범위이며, 이 작은 정책은 이미 전달한 바이트의 회수를 보장하지 않는다. 회수와 인가가 동시에 진행되는 경우에는 원장의 확정 순서가 판단 기준이고, 운영자는 요청별 판정 시각과 사용한 원장 버전을 남긴다.

필요한 원장을 읽지 못하면 신규 공유 제공을 보류한다. 이 선택은 가용성 비용을 가지므로 사용자에게 보류 사유와 재시도를 안내하고 원장 복구를 담당자에게 연결한다. 요청 크기·동시 다운로드와 감사 기록의 보호는 앞 장의 방어 원리를 적용하되, 이 절에서는 세계의 모든 유출·서비스 거부를 해결했다고 주장하지 않는다.

4. 요구·위협·통제·시험을 한 줄로 연결한다

R3 한 개에 Q4·Q5가 연결된다고 요구 수를 두 개로 세지 않는다. 시험 목록의 존재와 실제 실행·통과도 다른 상태다. 새 버전을 자동 공유하자는 요구가 생기면 R2, D2와 Q3의 기대 결과를 함께 검토해야 하며, 제목만 그대로 두고 구현만 바꾸지 않는다.

추적표는 시험을 할 이유와 결과를 적용할 범위를 알려 준다. 테스트가 모두 초록이어도 누락된 요구, 잘못 정한 기대값이나 위협 자체를 찾는 내용 검토까지 끝난 것은 아니다.

직접 풀기: 나머지 조건이 같을 때 무엇이 달라지는가

각 행은 SE-G1의 다른 조건이 유효한 별도 시험이다. 앞 행의 회수나 시간 변경을 다음 행에 누적하지 않는다. 표는 기대값이며 실제 운영 시험을 수행했다는 기록이 아니다.

만료시간을 30분이라고만 쓰면 시작·종료를 포함하는지 모호하다. 10:00:00에서 10:30:00까지 길이는 30분이지만 종료 시각의 신규 요청은 허용하지 않는다는 조건까지 써야 한다. 인증서 유효기간의 다른 비교 규칙을 이 자체 권한 정책에 복사하지 않는다.

5. 편한 대안이 어떤 요구를 포기하는지 비교한다

특정 저장소의 서명 URL도 수신자 결합·회수·우회 조건을 실제 기능과 구성으로 확인해야 한다. 제품 이름만으로 SE-G1을 만족하거나 만족하지 않는다고 단정하지 않는다. 캐시를 쓰려면 허용할 오래된 상태의 시간과 회수 요구를 명시적으로 조정해야 하며, 기존의 즉시 원장 대조 요구를 지킨 것처럼 보고하지 않는다.

신뢰 가능한 관리자와 원장이 함께 침해되는 경우, 정당한 수신자가 화면을 촬영하는 경우는 이 정책만으로 막지 못한다. 업무 책임자는 그런 잔여 위험과 자료 최소화·계약·기록 같은 다른 수단을 별도로 판단한다.

6. 설계가 바뀌면 어디로 돌아가야 하는가

NIST SSDF 1.1은 보안 실천을 개발 생명주기에 통합하고, 남은 취약점의 영향을 줄이며 근본 원인을 다루어 재발을 줄이는 방향을 제시한다. 보안을 마지막 도구 실행으로 한정하지 않는 근거다.[SE-C02]

SE-G1의 책임자는 수신자·기간·회수와 제외 범위를 승인한다. 설계 담당은 경계·원장·버전·제공 경로를 결정하고 개발 담당은 모든 다운로드 경로에서 이를 집행한다. 시험 담당은 정상 사용과 Q2~Q6의 실패 경계를 확인하며 운영 담당은 실제 원장 지연·회수·제공 결과를 관측한다. 보안 담당은 위협과 시험의 빈칸, 공통 원인으로 무너지는 통제와 남은 위험을 검토한다.

변경을 받으면 영향받는 요구·위협·통제·시험과 이미 생성된 공유 권한을 식별한다. 문서 버전 자동 갱신, 외부 수신자의 조직 변경, 원장 캐시 추가는 모두 재검토를 요구한다. 변경된 소스·정책·시험과 배포 버전을 연결하고, 회수된 요청이나 다른 버전이 제공되는 결함이 있으면 해당 변경의 출시를 보류한다.

문서가 많아져도 보안이 빠질 수 있다

위협마다 통제가 적혀 있지만 어떤 데이터에 적용하는지 정하지 않으면 제품 목록이다. 시험 ID가 있지만 기대값이 없으면 실행 결과를 평가할 수 없다. 위험수용 서명이 있어도 누가 어떤 근거로 어느 기간의 예외를 승인했는지 기록이 없으면 무기한 우회가 된다.

보안 실패를 해결하려고 만료 검사를 끄거나 원장 장애를 정상값으로 채우지 않는다. 정당한 요청을 계속 거부하는 문제도 확인해야 한다. 모든 요청을 거부하면 자료는 덜 나가지만 업무 목적을 충족한 시스템이 아니다. 허용과 거부 양쪽을 시험하고, 하지 않은 시험이나 모르는 잔여 위험은 그대로 남긴다.

공식 보안엔지니어링에서 담당하는 범위

이 절은 자산·신뢰경계에서 위협을 분석하고 검증 가능한 요구·아키텍처·시험·운영 변경으로 연결한다. 대상은 한시 문서 공유의 주체·행위·버전·기간·회수와 권한 원장이다. 경계는 요구와 구현 수단, 기대값과 시험 결과, 인증과 현재 인가의 구별이다. 실패는 잘못된 수신자·버전·만료·회수·원장 장애에서 미제공으로 판정한다. 전체 공격의 발견, 특정 제품의 완전한 구성, 실제 독립 인증이나 모든 유출 방지를 완료한 범위는 아니다.

7. 자체 10점 문제

SE-G1에서 공유 요구를 시험 가능한 문장으로 바꾸고, 만료 경계·수신자 변경·원장 조회 실패의 기대 결과와 요구 추적 방법을 설명하라.

요구어는 정의의 나열이 아니라 실제 조건의 전환을 요청한다. 30분이라는 길이와 종료 시각의 포함 여부, 신원이 확인된 사람과 지정 수신자를 구별한다. 아래 목차와 답안은 교육용 자체 예시이며 공식 채점표가 아니다.

먼저 G1의 허용 구간을 양 끝 기호로 적고 철회 시각에 들어온 새 요청을 판정한다. 화면의 버튼이 숨겨졌다는 관찰로 다운로드 경로까지 안전하다고 결론 내릴 수 있는지도 설명한다.

10점 자체 연습의 풀이와 완성 답안

답안 목차

1. 주체·객체·행위·조건을 갖춘 요구
2. 시각 경계와 불일치·미확인 판정
3. 요구·위협·통제·시험의 추적

현재 인가와 제공 집행 그림은 U7, D7 버전 4, 읽기, 10:00 이상 10:30 미만, 미회수라는 모든 조건을 신규 요청의 현재 원장으로 확인한다. 조건이 맞을 때만 제공하고 불일치·근거 부재는 미제공이다. 추적표는 위협 T를 요구 R, 통제 D, 기대값 있는 시험 Q에 연결한다.

완성 답안 예시

SE-G1은 인증된 감사자 U7에게만 문서 D7 버전 4의 읽기를 허용하고 서버 원장의 기간·회수 상태를 신규 요청마다 확인한다. 공유 주소를 어렵게 만드는 구현만 요구로 쓰지 않고, 다른 수신자·버전·행위에는 문서를 제공하지 않는 관측 가능한 결과를 명시한다.

유효구간은 같은 UTC 기준의 10:00:00 이상 10:30:00 미만이다. 10:29:59는 허용하지만 10:30:00은 거부하고, U8 요청은 인증 여부와 별개로 지정 수신자가 아니므로 거부한다. 필요한 원장 조회가 실패하면 과거 허용값을 쓰지 않고 보류·미제공한다. 이미 전달된 바이트의 회수는 이 정책이 보장하지 않는다.

T1~T4의 위협을 R1~R4의 요구, 서버 대조·버전 고정·기간 및 회수 검사·실패 보류 통제와 Q1~Q6 시험으로 연결한다. R3의 만료와 회수는 여러 시험으로 확인하되 요구 수를 중복 집계하지 않는다. 표에 시험이 존재한다는 사실을 실제 실행·통과나 전체 안전성으로 바꾸지 않는다.

8. 자체 25점 문제

외부 감사자를 위한 한시 문서 공유를 SE-G1에 따라 설계하라. 자산·경계·위협, 실제 요구와 집행 구조, 대안의 기각 이유, 담당·변경 검토·출시 보류 및 잔여 범위를 포함하라.

“보안 요구를 수립한다” 대신 실제 수신자·버전·시간과 실패 조건을 적는다. 위협모델은 시스템 설명과 연결하고 단순히 STRIDE 여섯 단어를 쓰는 것으로 대체하지 않는다.

답안을 펼치기 전에 요구 R1~R4를 테스트 Q1~Q6에 연결하되 R3의 두 시험 연결과 실행 건수를 분리한다. 원장이 멈춘 경우를 정상 다운로드와 같은 성공 기록으로 처리해도 되는지 근거를 적는다.

25점 자체 연습의 설계 이유와 완성 답안

설계 답안 목차

1. 자산·신뢰경계와 위협
2. 서버의 요구·집행·실패 처리
3. 대안과 남은 위험
4. 담당·변경·시험·출시 판단

공유 발급과 읽기 집행 그림에서 책임자의 범위 승인·서버 원장, 감사자의 인증·현재 권한·버전·기간·회수와 지정 버전 제공을 읽는다. 불일치·근거 부재는 거부·보류하여 기록한다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

문서 자동 갱신이나 원장 캐시 추가는 기존 승인과 기대값에 영향을 줄 수 있다. 영향을 식별해 요구·위협·시험을 갱신하고 재검증하며, 실패를 기대값 약화로 없애지 않는다.

완성 설계 답안 예시

자산은 보고서 내용과 공유 권한 원장이며 사용자 단말·공유 서비스·원장·저장소 사이의 신뢰경계를 표시한다. 다른 사람이 전달받은 주소 사용, 승인 뒤 버전 변경, 만료·회수 뒤 재사용, 원장 장애의 옛 허용값 사용을 위협으로 정한다. 신원 위장·변조·정보 노출·권한 상승 등의 관점은 질문을 확장하는 수단이지 위험 확률이나 위협 발견 완료의 증거가 아니다.

서버 원장에는 권한 있는 책임자가 승인한 U7·D7 버전 4·읽기·10:00:00 이상 10:30:00 미만을 기록한다. 신규 요청마다 인증 주체와 현재 원장·실제 버전·기간·회수를 대조하고 불일치이면 거부, 근거가 없으면 보류·미제공한다. 저장소 직접 접근과 캐시가 판정을 우회하지 않는지 확인하며 주체·요청·원장 버전·실제 제공 결과를 보호된 경로에 남긴다.

주소 소유만 확인하는 방식은 지정 수신자 요구를, 버튼만 숨기는 방식은 서버 만료 집행을 만족하지 못해 기각한다. 오래된 권한 캐시는 회수 반영을 늦출 수 있어 현재 정책에서는 선택하지 않는다. 원장 대조의 지연·장애 비용은 보류 안내와 복구 절차로 다루고, 이미 전송한 바이트·진행 중 전송·정당한 수신자의 재유출은 별도 잔여 범위로 명시한다.

업무 책임자는 공유·회수 범위, 설계 담당은 경계·원장·버전, 개발 담당은 모든 제공 경로, 시험 담당은 정상·실패 경계, 운영 담당은 회수와 실제 결과를 책임진다. 요구–위협–통제–시험을 추적하고 문서 자동 갱신·캐시 추가 등의 변경 때 영향받는 권한과 시험을 갱신한다. 다른 수신자·버전·만료·회수 뒤에도 제공되거나 미확인이 허용으로 바뀌면 출시를 보류한다. 자동검사와 별도로 기대값·누락 위협·업무 적합성을 검토한다.

9. 자기교정: 빠진 연결을 고치기

조건을 바꿔 설명하기

만료를 10:15:00으로 바꾸면? 다른 조건이 정상인 10:14:59 요청은 허용, 10:15:00은 거부다. 길이만 고치지 말고 원장과 경계 시험의 기대값을 같이 바꾼다.

문서 버전 5도 자동 공유하라는 요구가 생기면? 기존 R2의 승인 범위가 바뀐다. 책임자의 새 승인, 원장 표현, 제공할 버전의 고정과 Q3의 기대값을 함께 재설계한다. 기존 허용 결과를 재사용하지 않고 추적표에서 영향 범위를 찾는다.

모든 요청을 거부하면 안전한 설계인가? 정상 U7 요청까지 막아 업무 목적을 충족하지 못한다. 보안의 거부 조건뿐 아니라 정상 제공도 확인해야 한다. 실패 분석을 바탕으로 면접에서는 ‘기밀성만 높이는 선택의 업무 비용’을 설명한다.

회상으로 확인할 설계의 빈칸

G1을 다시 그리지 않고 말로 설명한다. 먼저 요청의 주체·D7 버전·행동을 고정하고, 다음으로 허용 시간이 끝나거나 철회된 경우를 배제한다. 마지막에는 제공한 결과와 원장 기록을 연결한다. 이 순서를 거꾸로 하여 먼저 파일을 제공하면 이후의 기록 실패로 이미 전달한 바이트를 되돌릴 수 없으므로, 원장 장애의 정책은 제공 전에 설계해야 한다. 이 설명은 이 절의 교육용 정책 선택이며 모든 서비스가 같은 장애 정책을 가져야 한다는 규칙은 아니다.

답안을 닫은 뒤 “10:30:00 요청”, “10:12:00 철회 뒤 새 요청”, “철회 전에 이미 전달된 바이트”, “원장 기록 실패”를 각각 한 문장으로 판정한다. 서로 다른 네 상태를 전부 “차단 완료”라고 답했다면 시간 비교와 실제 제공 여부를 먼저 분리해서 다시 쓴다.

2026-10-05에는 NIST SP 800-218, SSDF 1.1의 공식 발행 페이지와 적용 범위를 대조했다. 2022년 2월의 고수준 안전 개발 권고를 여러 SDLC에 결합하는 문서이며, 아래 자체 G1·R·Q 표의 수치나 채점기준이 NIST의 규범이라는 뜻은 아니다.

근거와 한계

SE-C01은 OWASP Threat Modeling Cheat Sheet의 Introduction·System Modeling·Threat Identification·Threat Response·Review and Validation과 STRIDE 설명을 사용했다. 관찰일은 2026-09-19이며 발행일이 확인됐다는 뜻은 아니다. SE-C02는 기존 보존 출처 SRC-DVO-SSDF11인 NIST SP 800-218 SSDF 1.1(2022-02 최종판)의 Abstract가 설명하는 생명주기 통합·취약점 영향·근본 원인 범위다. 기존 출처 관찰일을 이번 날짜로 덮어쓰지 않고 초안을 최종판처럼 인용하지 않는다.

SE-G1, T/R/D/Q 추적표·그림·질문·답안과 조건 변경은 자체 작성이다. 특정 클라우드 제품의 설정 명세나 법적 인증으로 사용하지 않는다. 보안엔지니어링·DevSecOps의 기존 정의 담당은 이 절에 유지하고 다음 절은 그 정의를 적용한다. 사람에 의한 독립 기술·시험·권리·초보 독자 검토는 미수행이다.

회독의 핵심

보호할 결과를 주체·객체·행위·조건과 시험 가능한 문장으로 만든다. 위협을 실제 경계와 연결하고 요구–통제–시험–운영 변경의 흔적을 유지한다. 기능이 존재하는 것과 우회 없이 집행되는 것, 시험 계획과 통과는 다르다. 뒤의 보안검증 절에서는 이 기대값을 실제 관측과 비교하고 취약점 조치의 완료까지 판정한다.

조건을 바꾸어 연습하기: 오래된 허용·회수 순서·시험 집계를 추적한다.

세 사례는 SE-G1의 신규 요청 정책을 기준으로 한다. 시간은 모두 같은 신뢰 가능한 UTC이며 다른 수신자·문서·행위 조건은 유효하다고 가정한다. 시험 기록은 연습용으로 주어진 관측값이다.

1. SE-C. 10:10:00에 현재 원장의 미회수 상태를 읽어 5분 동안 캐시했다. 캐시는 10:15:00부터 만료된다. 회수는 원장에 10:12:00 확정됐는데, 10:13:00의 신규 요청이 캐시의 허용값으로 문서를 받았다. 링크의 원래 만료는 10:30:00이다. SE-G1을 충족하는가? 캐시 만료 전까지 오래된 회수 상태가 남을 수 있는 구간 길이는 얼마인가? 캐시 수명만 줄이면 ‘신규 요청마다 현재 원장 대조’ 요구를 자동으로 만족하는가?
2. SE-R. 원장의 확정 순서를 E100, E101, E102로 기록했다. E100에서 신규 요청 A가 유효한 미회수 원장을 대조하여 인가됐고 전송을 시작했다. E101에서 회수가 확정됐다. E102에서 다른 신규 요청 B가 회수된 현재 원장을 대조했다. A와 B를 각각 어떻게 판정하는가? A가 이미 받은 바이트와 진행 중인 전송까지 모두 취소됐다고 결론 내릴 수 있는가? B의 현재 원장 조회가 실패했을 때 E100의 성공값을 사용해도 되는가?
3. SE-T. 기존 추적표의 시험 묶음 Q1~Q6을 사용한다. Q1·Q2·Q5·Q6은 제시한 기대값과 일치했다. Q3은 미실행이다. Q4에서는 10:29:59가 허용되어 일치했으나 10:30:00에도 허용되어 불일치했다. 묶음의 모든 하위 조건이 일치해야 그 묶음을 통과로 센다. 계획·실행·통과·실패·미실행 묶음 수를 각각 구하라. 한 요구에 연결된 모든 시험 묶음이 실행·통과해야 ‘이 표의 시험 근거 충족’으로 센다면 R1~R4 중 어느 요구가 충족하는가? Q5 통과로 R3을 충족했다고 하거나 4/5를 전체 보안의 확률이라고 해도 되는가?

캐시 회수 지연·원장 확정 순서·요구별 시험 근거 풀이

1. SE-C — 링크의 만료 전이어도 현재 회수 조건은 별개다. 10:13:00은 10:30:00보다 이르지만, 현재 원장은 이미 회수 상태다. 캐시를 신뢰해 새로 제공했으므로 SE-G1을 위반한다. 이 캐시 사례에서는 회수 확정 10:12:00부터 만료 10:15:00 전까지 3분, 즉 180초 동안 옛 상태가 남을 수 있다. 이는 주어진 캐시 시각의 계산이며 모든 구현의 최대 지연을 실측한 값이 아니다.

캐시 수명을 짧게 해도 양의 지연 동안 새 요청이 옛 상태를 쓸 가능성은 남는다. 현재 원장 대조를 실제로 집행하거나 현재 회수 상태와 일치하도록 하는 별도 설계를 검증해야 한다. 지연을 허용하려면 책임자가 요구를 바꾸고 R3·D3·Q5와 기존 발급 권한의 영향을 재검토한다. 단순히 Q5의 기대값을 옛 캐시 성공으로 낮추어 원 요구를 만족했다고 쓰지 않는다.

2. SE-R — 원장에 대한 인가와 회수의 순서를 기준으로 나눈다. A는 E100에서 당시 유효한 권한으로 인가됐으므로 최초 인가가 회수 뒤의 잘못된 신규 인가는 아니다. B는 E101 뒤의 현재 원장을 읽었으므로 거부·미제공이다. 벽시계 표시가 같아도 여기서는 명시한 확정 순서가 판단 근거이며 사용한 원장 버전과 판정·실제 제공 결과를 함께 기록한다.

이미 A에 전달한 바이트를 회수했다는 결론은 낼 수 없다. 진행 중인 전송을 언제 어떻게 종료할지는 원 정책의 잔여 범위여서 별도 정책과 구현·시험이 필요하다. B가 현재 원장을 읽지 못하면 필요한 근거가 없으므로 보류·미제공한다. E100의 성공은 다른 요청과 이전 원장 상태에 대한 결과이므로 B의 현재 인가를 대신하지 못한다.

3. SE-T — 시험의 묶음과 요구의 분모를 구별한다. 계획 6묶음, 실행 5묶음, 통과 4묶음, 실패 1묶음(Q4), 미실행 1묶음(Q3)이다. Q4의 하위 조건 중 하나가 실패했으므로 묶음 전체는 실패다. 시험별 사례·관측값은 보존하여 어느 경계에서 틀렸는지도 남긴다.

R1은 Q1·Q2가 모두 통과하여 충족하고 R4도 Q6이 통과하여 충족한다. Q6의 기대 결과는 보류·미제공이므로 다운로드가 안 됐다고 시험 실패로 바꾸지 않는다. R2는 Q3 미실행으로 근거가 부족하고 R3은 Q4 실패 때문에 Q5가 통과해도 충족하지 못한다. 이 표에서는 4요구 중 2요구의 시험 근거가 충족된다. 4/5=80%는 실행한 시험 묶음의 통과 비율일 뿐, 미실행을 포함한 완료도·공격 차단 확률·전체 시스템 안전성은 아니다. 만료 경계 결함을 고치고 Q4를 재실행하며 Q3도 실제 실행한 뒤 요구별 결과를 다시 판단한다.