23년 1회차

검증(인증)을 마친 사용자에게 시스템 자원 접근을 허락하는 과정은 Authorization(인가)이다.

접근통제는 식별 → 인증 → 인가 → 책임추적 순으로 진행되며, 인가는 인증된 주체에게 어떤 자원에 어떤 권한으로 접근할지를 부여하는 단계다.

• Authentication(인증): 사용자가 주장하는 신원이 맞는지 검증하는 단계로, 발문의 '검증을 마친' 부분에 해당한다.
• Audit(감사): 기록된 활동 로그를 검토해 정책 위반·이상 행위를 확인하는 활동이다.
• Accounting(책임추적): 사용자의 자원 사용 내역을 기록·추적하는 기능이다.

추가 비용이나 외부 연계 없이 위험을 감수하거나 기능 사용을 포기하는 방식은 위험 수용과 위험 회피다.

위험 수용은 잠재적 위험을 그대로 받아들이는 것이고, 위험 회피는 위험을 유발하는 시스템 기능·업무 자체를 포기해 위험을 없애는 것이다.

• ㄱ, ㄹ 조합: 위험 전가는 보험·외주 계약 등 외부와 연계해 위험을 제3자에게 넘기는 방식이라 해당하지 않는다.
• ㄴ, ㄷ 조합: 위험 감소는 보안 대책 도입에 추가 비용을 투입하는 방식이라 해당하지 않는다.
• ㄷ, ㄹ 조합: 위험 감소와 위험 전가 모두 비용 투입이나 외부 연계가 필요하다.

해시 충돌은 같은 해시 함수에 서로 다른 입력을 넣었는데 출력이 같은 경우, 즉 $h_1(k_1) = h_1(k_2)$이다.

충돌 저항성은 $k_1 \neq k_2$이면서 $h(k_1) = h(k_2)$인 입력 쌍을 찾기 어려워야 한다는 성질이다.

• $h_1(k_1) = h_2(k_1)$: 서로 다른 두 함수에 같은 입력을 넣어 비교한 것으로, 충돌의 정의와 무관하다.
• $h_1(k_1) \neq h_1(k_2)$: 서로 다른 입력의 출력이 다른 정상적인 경우다.
• $h_1(k_1) \neq h_2(k_2)$: 다른 함수·다른 입력의 출력을 비교한 것으로, 충돌과 관계없다.

MAC은 메시지 길이와 관계없이 고정 길이로 출력되므로, 메시지 길이와 같다는 설명이 옳지 않다.

MAC은 공유 비밀키와 메시지를 입력으로 짧은 고정 길이 태그를 만들어 메시지에 덧붙인다.

• 송·수신자가 공유 비밀키를 가져야 MAC을 생성·검증할 수 있다.
• MAC은 메시지와 함께 전달되고, 수신자가 다시 계산해 비교함으로써 무결성을 검증한다.
• 비밀키를 아는 송신자만 올바른 MAC을 만들 수 있으므로 수신자는 메시지 출처를 확인(메시지 인증)할 수 있다.

chmod 2755 를 실행하면 파일 권한은 -rwxr-sr-x가 된다.

맨 앞 자리 2는 특수권한 중 SetGID(4는 SetUID, 1은 Sticky Bit)를 뜻하고, 755는 소유자 rwx·그룹 r-x·기타 r-x다. SetGID가 설정되면 그룹 실행 자리의 x가 s로 표시된다.

• -rwxr-xr-x: 특수권한이 없는 755의 표시다.
• -rwsr-xr-x: 소유자 실행 자리에 s가 있는 SetUID(4755)의 표시다.
• -rwsr-sr-x: SetUID와 SetGID가 모두 설정된 6755의 표시다.

국가정보원장에게 우선적으로 기술적 지원을 요청해야 하는 시설에서 금융 정보통신기반시설 등 개인정보가 저장된 시설은 제외된다.

「정보통신기반 보호법」은 국가안전보장에 중대한 영향을 미치는 시설로 주요 교통시설, 에너지·수자원 시설, 방송중계·국가지도통신망 시설, 원자력·국방과학·첨단방위산업 관련 정부출연연구기관의 연구시설을 들되, 금융 등 개인정보가 저장된 시설은 단서로 제외한다.

• 도로·철도·지하철·공항·항만 등 주요 교통시설은 우선 지원 요청 대상이다.
• 전력·가스·석유 등 에너지·수자원 시설은 우선 지원 요청 대상이다.
• 원자력·국방과학·첨단방위산업 관련 정부출연연구기관의 연구시설은 우선 지원 요청 대상이다.

AES 복호화는 ARK → ISR → ISB → ARK 순으로 시작한다.

복호화는 먼저 마지막 라운드 키로 Add Round Key를 수행한 뒤, 각 라운드에서 Inverse Shift Rows → Inverse Substitute Bytes → Add Round Key → Inverse Mix Columns 순으로 진행한다(마지막 라운드는 IMC 생략).

• ARK － IMC － ISR － ISB: 초기 ARK 다음에는 ISR이 오며, IMC는 라운드 안에서 ARK 뒤에 수행된다.
• ARK － ISB － ISR － IMC: ISB·ISR 다음에 라운드 키 덧셈(ARK) 없이 IMC가 와 라운드 구조에 어긋난다.
• IMC － ISR － ISB － ARK: 복호화는 반드시 초기 ARK로 시작하므로 IMC로 시작할 수 없다.

(가)는 정보통신서비스 제공자, (나)는 정보보호 최고책임자다.

정보통신망법 제45조의3은 정보통신서비스 제공자가 정보통신시스템 보안과 정보의 안전한 관리를 위해 임직원을 정보보호 최고책임자(CISO)로 지정하고 과학기술정보통신부장관에게 신고하도록 규정한다.

• 정보통신서비스 제공자 / 개인정보 보호책임자: 개인정보 보호책임자는 개인정보 처리 업무를 총괄하는 「개인정보 보호법」상 책임자로, 이 조문의 지정 대상이 아니다.
• 개인정보처리자 / 정보보호 최고책임자: 이 조문의 지정·신고 의무 주체는 개인정보처리자가 아니라 정보통신서비스 제공자다.
• 개인정보처리자 / 개인정보 보호책임자: 주체와 지정 대상 모두 「개인정보 보호법」의 용어로, 이 조문과 맞지 않는다.

패스워드 최소·최대 사용 기간은 chage 명령으로 지정하고, 그 결과는 /etc/shadow에 저장된다.

chage의 -m(최소 사용 기간)·-M(최대 사용 기간) 옵션으로 설정한 값은 /etc/shadow의 패스워드 에이징 필드에 기록된다.

• usermod / /etc/passwd: 명령어와 파일 모두 틀렸다. usermod는 홈 디렉터리·셸·그룹 등 계정 속성을 수정하는 명령이다.
• chage / /etc/passwd: 명령어는 맞지만 /etc/passwd에는 사용자명·UID·홈 디렉터리 등 기본 정보만 있고 패스워드 에이징 정보는 없다.
• usermod / /etc/shadow: 파일은 맞지만 패스워드 최소·최대 사용 기간을 지정하는 명령은 chage다.

SYN Flooding에 대응하려면 TCP 연결 테이블(백로그 큐)의 크기를 늘려야 하므로, 감소시킨다는 설명이 옳지 않다.

SYN Flooding은 응답 없는 SYN 요청으로 반개방(half-open) 연결을 쌓아 큐를 가득 채우는 공격이므로, 백로그 확대·대기 시간 단축·SYN Cookie 등으로 대응한다.

• Smurf 공격: 브로드캐스트 주소로 가는 ICMP Echo 요청을 증폭에 악용하므로, 이를 차단하는 대응은 옳다.
• Land 공격: 출발지와 목적지 IP가 같은 패킷으로 시스템을 교란하므로, 이런 패킷을 차단하는 대응은 옳다.
• Slowloris 공격: 불완전한 HTTP 요청으로 연결을 오래 점유하므로, 요청 개수와 연결 유지 시간을 제한하는 대응은 옳다.

XOR 패리티를 쓰고 패리티 블록을 전체 디스크에 분산 저장하는 방식은 RAID 5다.

RAID 5는 블록 단위 스트라이핑과 분산 패리티를 사용해, 패리티 디스크 하나에 쓰기가 몰리는 병목을 없앤다.

• RAID 1: 같은 데이터를 두 디스크에 복제하는 미러링으로, 패리티를 쓰지 않는다.
• RAID 3: 바이트 단위 스트라이핑에 전용 패리티 디스크 하나를 둔다.
• RAID 4: 블록 단위 스트라이핑에 전용 패리티 디스크 하나를 두므로 패리티가 분산되지 않는다.

객체 소유자가 자율적으로 접근 권한을 정하는 방식은 임의적 접근 제어(DAC)다.

DAC는 주체의 신원과 소유자가 정한 접근 제어 목록(ACL) 등에 따라 권한을 부여하며, 소유자가 다른 사용자에게 권한을 넘겨줄 수 있다.

• 강제적 접근 제어(MAC): 시스템이 주체의 보안 인가 등급과 객체의 보안 레이블을 비교해 강제로 통제하며, 소유자가 임의로 바꿀 수 없다.
• 역할 기반 접근 제어(RBAC): 사용자에게 부여된 역할(직무)에 권한을 연결해 통제한다.
• 래티스 기반 접근 제어: 보안 등급의 격자(lattice) 구조에 따라 접근을 통제하는 강제적 방식의 일종이다.

그림의 순환은 Plan → Do → Check → Act의 PDCA 사이클이므로 (가)는 Do, (나)는 Check, (다)는 Act이다.

ISO 27001의 관리 체계는 이해관계자의 정보보호 요구사항과 기대를 입력으로 받아 수립(Plan) → 구현·운영(Do) → 모니터링·검토(Check) → 유지·개선(Act)을 반복하고, 그 결과로 관리되는 정보보호를 산출한다. 그림에서 Plan 다음 화살표가 (가), (나), (다)를 차례로 거쳐 다시 Plan으로 돌아온다.

• Check / Act / Do: 수립 직후에 점검을 두어 구현 단계보다 검토가 먼저 오므로 순서가 맞지 않는다.
• Check / Do / Act: 역시 구현보다 점검이 먼저 와 Do가 Plan 바로 다음이라는 원칙에 어긋난다.
• Do / Act / Check: 구현 후 개선을 먼저 하고 점검을 나중에 두어, 점검 결과를 근거로 개선하는 흐름과 반대이다.

샌드박스는 재전송 공격을 방지하는 수단이 아니다.

샌드박스는 신뢰할 수 없는 코드를 격리된 환경에서 실행해 시스템을 보호하는 기술로, 이전 메시지를 다시 보내는 공격을 막는 메시지 신선도 확인과 무관하다.

• 시퀀스 번호: 메시지마다 증가하는 번호를 붙여 중복되거나 순서가 어긋난 메시지를 탐지한다.
• 타임 스탬프: 메시지 생성 시각을 넣어 허용 시간을 벗어난 오래된 메시지를 거부한다.
• 비표(nonce): 한 번만 쓰는 난수를 사용해 이전 세션 메시지의 재사용을 탐지한다.

송신 측 SSL Record 프로토콜의 처리 순서는 단편화 → 압축 → MAC 추가 → 암호화다.

응용 데이터를 레코드 크기로 나눈 뒤 압축하고, 압축된 데이터에 MAC을 계산해 덧붙인 다음 데이터와 MAC을 함께 암호화하고 레코드 헤더를 붙인다.

• 단편화 － 암호화 － MAC 추가 － 압축: 암호화가 MAC 추가보다 앞서고 압축이 맨 뒤에 있어 틀렸다.
• 단편화 － MAC 추가 － 암호화 － 압축: 암호문은 무작위성이 높아 압축 효과가 없으므로 압축은 암호화 전에 해야 한다.
• 압축 － MAC 추가 － 암호화 － 단편화: 단편화가 가장 먼저 수행되어야 한다.

개인정보 보호 인증의 유효기간은 3년이며, 사후관리는 연 1회 이상 실시한다.

「개인정보 보호법」은 인증의 유효기간을 3년으로 정하고, 시행령은 인증의 실효성 유지를 위해 연 1회 이상 사후관리를 하도록 규정한다.

• 2년 / 연 1회 이상: 사후관리 주기는 맞지만 유효기간이 틀렸다.
• 2년 / 연 2회 이상: 유효기간과 사후관리 주기가 모두 틀렸다.
• 3년 / 연 2회 이상: 유효기간은 맞지만 사후관리 주기가 틀렸다.

Snort는 시그니처(규칙) 기반 오용 탐지 IDS이므로, 정상행위 프로파일과 비교해 탐지한다는 설명이 옳지 않다.

정상행위 프로파일과의 비교는 이상(anomaly) 탐지 방식이며, Snort는 알려진 공격 패턴을 규칙으로 기술해 패킷과 대조한다.

• Snort는 오픈 소스 네트워크 기반 침입 탐지 시스템으로 개발되었다.
• 규칙의 동작 설정에 따라 패킷 삭제(인라인 모드), 로그 기록, 경고 생성 기능을 제공한다.
• 관리자가 직접 침입 탐지 규칙을 작성해 적용할 수 있다.

사용자 브라우저를 통해 공격자가 의도한 요청이 사용자 권한으로 실행되게 하는 공격은 CSRF(사이트 간 요청 위조)다.

CSRF는 서버가 인증된 사용자 브라우저의 요청을 신뢰한다는 점을 악용해, 사용자가 모르게 위조 요청을 보내게 한다.

• 저장형 XSS: 악성 스크립트를 게시판 등 서버에 저장해 열람한 사용자 브라우저에서 실행되게 하는 공격으로, 서버에 명령을 대신 보내게 하는 것이 핵심이 아니다.
• 반사형 XSS: URL 파라미터 등에 담긴 스크립트가 응답에 그대로 반사되어 사용자 브라우저에서 실행되는 공격이다.
• XXE: XML 파서가 외부 엔티티를 처리하는 점을 악용해 서버 파일 열람 등을 일으키는 공격이다.

(가)는 RST, (나)는 Sequence다.

공격자는 RST 세그먼트로 서버 측 연결을 잠시 Closed 상태로 만든 뒤, 스니핑으로 얻은 정보로 조작한 시퀀스 번호를 사용해 서버와 새 연결을 맺어 세션을 가로챈다.

• FIN / Sequence: FIN은 정상 종료 절차를 시작하는 플래그로, 서버 연결을 즉시 Closed로 만드는 용도가 아니다.
• FIN / Acknowledgment: 사용하는 플래그와 조작하는 번호가 모두 틀렸다.
• RST / Acknowledgment: 새 연결 설정에서 공격자가 조작해 맞추는 값은 확인 번호가 아니라 시퀀스 번호다.

A의 비밀키는 $(Y_A)^{X_{D2}} \bmod q$, B의 비밀키는 $(Y_B)^{X_{D1}} \bmod q$이며, 두 키는 각각 D와 공유된다.

A는 $Y_{D2}$를 받아 계산한다.
$(Y_{D2})^{X_A} = \alpha^{X_{D2} X_A} = (Y_A)^{X_{D2}} \bmod q$
B는 $Y_{D1}$을 받아 계산한다.
$(Y_{D1})^{X_B} = \alpha^{X_{D1} X_B} = (Y_B)^{X_{D1}} \bmod q$

• $(Y_A)^{X_{D1}}$ / $(Y_B)^{X_{D2}}$: A는 $Y_{D2}$, B는 $Y_{D1}$을 받았으므로 D의 개인키 짝이 뒤바뀌었다.
• $(Y_B)^{X_{D2}}$ / $(Y_A)^{X_{D1}}$: A는 $X_A$만 사용하므로 A의 키는 $Y_A$로 표현되어야 하며, 공개키가 서로 뒤바뀌었다.
• $(Y_B)^{X_{D1}}$ / $(Y_A)^{X_{D2}}$: A와 B의 비밀키가 서로 뒤바뀐 것이다.

CCMP에 대한 옳은 설명은 동일한 128비트 키 사용과 CBC-MAC 기반 무결성이다.

CCMP는 AES를 CCM 모드(CTR 모드 암호화 + CBC-MAC 인증)로 사용하며, 기밀성과 무결성에 같은 128비트 키를 쓴다.

• ㄱ, ㄷ 조합: 데이터 암호화에는 CBC가 아니라 CTR 모드를 사용하므로 ㄷ이 틀렸다.
• ㄴ, ㄷ 조합: Michael MIC는 TKIP의 무결성 방식이고 암호화 모드도 CTR이라 둘 다 틀렸다.
• ㄴ, ㄹ 조합: Michael 알고리즘은 CCMP가 아니라 TKIP에서 사용하므로 ㄴ이 틀렸다.

TCP 체크섬은 전송 오류를 검출할 뿐 의도적인 위·변조는 탐지할 수 없으므로, 이 설명이 옳지 않다.

체크섬은 비밀키 없이 누구나 계산할 수 있어 공격자가 데이터를 바꾼 뒤 체크섬을 다시 계산하면 그만이며, 위·변조 탐지에는 MAC 같은 암호학적 무결성 수단이 필요하다.

• 포트 번호로 응용 서비스를 구분하므로 방화벽 등에서 응용별 접근통제 정책을 설정할 수 있다.
• SYN Flooding은 3-way handshaking에서 SYN만 보내고 응답하지 않아 반개방 연결을 쌓는 공격이다.
• TCP 포트 스캐닝으로 열린 포트를 확인해 동작 중인 서비스를 파악할 수 있다.

SEED 128은 Feistel 구조이므로, SPN 구조라는 설명이 옳지 않다.

SEED는 128비트 평문 블록과 128비트 키를 입력으로 16라운드 Feistel 구조를 거쳐 128비트 암호문을 출력한다. SPN 구조를 쓰는 대표 블록 암호는 AES·ARIA다.

• SEED는 1999년 2월 국내 기술로 개발된 128비트 블록 암호 알고리즘이다.
• 라운드 키는 128비트 키를 64비트씩 나누어 얻은 4개 워드에 간단한 산술 연산과 G 함수를 적용해 생성한다.
• 1999년 9월 TTA 표준으로 제정되었고, 2005년 ISO/IEC와 IETF 표준으로 채택되었다.

인증 및 권한관리는 개인정보 처리 단계별 요구사항이 아니라 보호대책 요구사항에 속한다.

ISMS-P의 개인정보 처리 단계별 요구사항은 수집 시, 보유·이용 시, 제공 시, 파기 시 보호조치와 정보주체 권리보호로 구성된다.

• 개인정보 수집 시 보호조치: 처리 단계별 요구사항의 첫 영역이다.
• 개인정보 보유 및 이용 시 보호조치: 처리 단계별 요구사항에 속한다.
• 정보주체 권리보호: 처리 단계별 요구사항의 마지막 영역이다.

쿠키를 저장한 클라이언트가 다시 요청할 때는 헤더 라인의 Cookie 필드에 쿠키를 담아 보낸다.

서버는 응답 헤더의 Set-Cookie로 쿠키를 내려주고, 브라우저는 이후 같은 도메인으로 보내는 요청 헤더의 Cookie 필드에 저장된 값을 포함한다.

• 요청 라인의 Set-Cookie: 요청 라인은 메서드·URL·버전만 담으며, Set-Cookie는 서버 응답에서 쓰는 헤더다.
• 헤더 라인의 Set-Cookie: Set-Cookie는 서버가 응답에 넣는 헤더로, 클라이언트 요청에는 쓰지 않는다.
• 요청 라인의 Cookie: 쿠키는 요청 라인이 아니라 헤더 라인에 담긴다.