식별·인증·인가·책임추적
사용자 이름을 입력한 것은 자신이 누구인지 주장한 것이고, 비밀번호나 장치로 확인한 것은 그 주장을 검증한 것이다. 확인된 사용자라도 다른 사람의 급여를 바꿀 권한이 있는지는 별도 판단이다. 작업 뒤에는 누가 언제 어떤 근거로 무엇을 했는지 재구성할 수 있어야 한다.
로그인했다는 사실만으로 모든 행동을 허용할 수 없다
사용자 이름을 입력한 것은 자신이 누구인지 주장한 것이고, 비밀번호나 장치로 확인한 것은 그 주장을 검증한 것이다. 그런데 확인된 사용자라도 다른 사람의 급여를 바꿀 권한이 있는지는 따로 판단해야 한다. 그리고 작업이 끝난 뒤에는 누가 언제 어떤 권한으로 무엇을 했는지 다시 짜 맞출 수 있어야 한다.
식별·인증·인가·책임추적
식별은 주체가 자신이 누구인지 나타내는 식별자를 제시하는 단계다. 인증(authentication)은 그 식별 주장에 연결된 인증수단을 검증하는 과정이다. 인가(authorization)는 인증된 주체가 특정 객체에 특정 행위를 할 수 있는지 정책으로 결정하는 과정이다. 책임추적성(accountability)은 행위와 결과를 주체·시간·결정 사유에 연결해 나중에 입증할 수 있는 성질이다.
이 장의 온라인 계정 사례에서 인증이 확인하는 것은, 그 계정에 연결된 비밀이나 인증장치를 요청자가 가지고 통제한다는 사실이다. 이것만으로 실제 사람의 법적 신원까지 완전히 증명되지는 않는다. 신원확인과 계정·인증수단의 등록은 별도 과정이므로, 수단이 잘못 등록되어 있으면 인증이 성공해도 엉뚱한 사람에게 연결될 수 있다.
생체 특징도 비밀키처럼 교체할 수 있는 비밀로 보지 않는다. 그래서 NIST의 디지털 인증 지침은 생체를 단독 인증수단으로 쓰지 않고 물리적 인증수단과 함께 사용하도록 조건을 둔다. 실제 구성에서는 적용하는 기준과 장치의 보호조건까지 확인한다.
주장–검증–결정–기록의 흐름
주체가 계정과 인증수단을 제시하면 시스템은 신뢰할 수 있는 등록정보와 대조한다. 인증에 성공한 뒤에도 인가는 따로 판단하는데, 이때 자원과 행위, 역할·속성, 시간과 위험신호를 함께 본다. 결정과 실제 실행 결과는 시간이 동기화된 기록으로 남기고, 그 기록에 대한 접근과 변경도 보호한다. 반대로 공용계정은 여러 사람의 행위를 한 주체로 합쳐 버리므로 책임추적을 약하게 만든다.
인증이 강해도 권한이 넓으면 안전하지 않다
다중 인증은 계정 도용 가능성을 낮추지만 과도한 권한을 고치지는 않는다. 또 인가검사를 화면에만 두고 서버가 검사하지 않으면 요청을 직접 보내 우회할 수 있다. 로그가 있어도 주체 식별과 결정 사유, 결과, 시간이 빠져 있거나 나중에 바꿀 수 있다면 증적이 되기 어렵다. 그래서 세 단계와 기록을 각각 따로 시험해야 한다.
요청이 허용되고 나중에 입증되기까지
인증 성공 뒤에도 인가에서 거부되면 집행하지 않는다 · 상태 따라가기
인증한 A의 현재 조직·요청 행위를 고정한다. 모든 단계에서 인증된 주체·인가·집행의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.
상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.
급여 담당자 A의 주장과 증거를 확인한 뒤 주체·객체·행위·조건·정책 v1로 인가한다. 같은 조직·유효 변경권·다른 승인자를 모두 요구한다. 허용의 집행 성공/실패와 거부의 변경 0회는 각각 기록한다. 기록의 접근·변경·보존과 사후검토를 보호한다.
이 예의 조건
- 급여 담당자 A의 주장과 증거를 확인한 뒤 주체·객체·행위·조건·정책 v1로 인가한다. 같은 조직·유효 변경권·다른 승인자를 모두 요구한다. 허용의 집행 성공/실패와 거부의 변경 0회는 각각 기록한다. 기록의 접근·변경·보존과 사후검토를 보호한다.
- 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.
관계도의 보충 설명
| 대상 | 원 설명 |
|---|---|
| 식별 주장 | 계정·장치 식별자 제시 |
| 인증 증거 검증 | 비밀번호·등록장치 등 |
| 인가 허용? | 정책·조건 |
| 서버 집행 | 허용된 읽기·변경·실행 / 실제 성공/실패 확인 |
| 보호 행위 미실행 | 거부 결과 반환 / 변경 0회 |
| 책임추적 기록 | 주체·시간·대상·행위 / 결정·실행/거부 결과 / 정책 판본·기록 변경 보호 |
| 연결 | 원 라벨·방향 |
|---|---|
| 식별 주장 → 인증 증거 검증 | 신뢰정보 / 정방향 / 실선 |
| 인증 증거 검증 → 인가 허용? | 인증 성공 / 정방향 / 실선 |
| 인가 허용? → 서버 집행 | 허용 / 정방향 / 실선 |
| 인가 허용? → 보호 행위 미실행 | 거부 / 정방향 / 실선 |
| 서버 집행 → 책임추적 기록 | 집행 결과 / 정방향 / 실선 |
| 보호 행위 미실행 → 책임추적 기록 | 거부 결과 / 정방향 / 실선 |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 신원과 대상 인증한 A의 현재 조직·요청 행위를 고정한다. |
|
|
| 현재 정책 판정 정책 v1로 현재 대상·행위를 허용하거나 거부한다. |
|
|
| 실제 집행·기록 허용 행위만 실행하고 거부는 변경 없음으로 기록한다. |
|
|
인증 성공 뒤에도 인가에서 거부되면 집행하지 않는다 · 상태 따라가기
인증한 A의 현재 조직·요청 행위를 고정한다. 모든 단계에서 인증된 주체·인가·집행의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.
상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.
급여 담당자 A의 주장과 증거를 확인한 뒤 주체·객체·행위·조건·정책 v1로 인가한다. 같은 조직·유효 변경권·다른 승인자를 모두 요구한다. 허용의 집행 성공/실패와 거부의 변경 0회는 각각 기록한다. 기록의 접근·변경·보존과 사후검토를 보호한다.
이 예의 조건
- 급여 담당자 A의 주장과 증거를 확인한 뒤 주체·객체·행위·조건·정책 v1로 인가한다. 같은 조직·유효 변경권·다른 승인자를 모두 요구한다. 허용의 집행 성공/실패와 거부의 변경 0회는 각각 기록한다. 기록의 접근·변경·보존과 사후검토를 보호한다.
- 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.
관계도의 보충 설명
| 대상 | 원 설명 |
|---|---|
| 식별 주장 | 계정·장치 식별자 제시 |
| 인증 증거 검증 | 비밀번호·등록장치 등 |
| 인가 허용? | 정책·조건 |
| 서버 집행 | 허용된 읽기·변경·실행 / 실제 성공/실패 확인 |
| 보호 행위 미실행 | 거부 결과 반환 / 변경 0회 |
| 책임추적 기록 | 주체·시간·대상·행위 / 결정·실행/거부 결과 / 정책 판본·기록 변경 보호 |
| 연결 | 원 라벨·방향 |
|---|---|
| 식별 주장 → 인증 증거 검증 | 신뢰정보 / 정방향 / 실선 |
| 인증 증거 검증 → 인가 허용? | 인증 성공 / 정방향 / 실선 |
| 인가 허용? → 서버 집행 | 허용 / 정방향 / 실선 |
| 인가 허용? → 보호 행위 미실행 | 거부 / 정방향 / 실선 |
| 서버 집행 → 책임추적 기록 | 집행 결과 / 정방향 / 실선 |
| 보호 행위 미실행 → 책임추적 기록 | 거부 결과 / 정방향 / 실선 |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 신원과 대상 인증한 A의 현재 조직·요청 행위를 고정한다. |
|
|
| 현재 정책 판정 정책 v1로 현재 대상·행위를 허용하거나 거부한다. |
|
|
| 실제 집행·기록 허용 행위만 실행하고 거부는 변경 없음으로 기록한다. |
|
|
그림은 급여 담당자 A의 요청이 식별 주장과 인증 검증을 거쳐 인가 판정에 이르고, 정책 v1이 허용한 경우에만 서버가 집행하는 흐름이다. 거부된 요청은 보호행위를 실행하지 않고 변경 0회라는 거부 결과만 기록으로 넘어간다. 이처럼 각 단계의 입력과 실패를 분리해야 원인을 찾을 수 있다. 예를 들어 등록정보가 틀리면 올바른 인증수단도 다른 사람과 연결될 수 있고, 인가정책이 틀리면 인증에 성공한 사용자가 과도한 행동을 할 수 있다. 결정 로그만 있고 실제 실행결과가 없으면 허용 후 성공·실패를 재구성할 수 없다.
네 개념을 질문·입력·결과로 구분한다
| 구분 | 핵심 질문 | 주된 입력 | 결과 |
|---|---|---|---|
| 식별 | 누구라고 주장하는가 | 계정명·장치 식별자 | 주장된 주체 |
| 인증 | 식별 주장에 연결된 인증수단이 유효한가 | 등록된 비밀·인증장치 등 인증수단 | 인증 성공·실패와 신뢰수준 |
| 인가 | 이 주체가 이 행동을 해도 되는가 | 주체·객체·행위·속성·정책 | 허용·거부·조건 |
| 책임추적 | 무엇이 실제로 일어났음을 입증할 수 있는가 | 결정·실행·시간·변경보호 기록 | 행위 재구성과 책임 연결 |
로그인은 보통 식별과 인증을 포함하지만 인가 전체를 대신하지는 않는다. 로그인 사용자만 접근은 시작조건일 뿐이다. 어떤 고객의 어떤 필드를 읽거나 바꿀 수 있는지는 요청마다 다시 결정해야 한다.
강한 통제와 업무 가능성을 함께 설계한다
인증단계를 무조건 늘리면 계정탈취 위험은 낮아질 수 있다. 그러나 사용자가 공용계정이나 우회경로를 찾게 되거나 긴급업무가 멈출 수 있다. 권한을 아주 잘게 나누면 피해범위는 줄지만 승인과 정책 관리가 복잡해진다. 모든 세부행동을 기한 없이 기록하면 책임추적은 쉬워져도 민감정보 노출과 저장비용이 늘어난다.
따라서 행동의 위험에 따라 인증 강도와 재인증 시점을 정하고, 역할만으로 부족하면 자원·시간·장치·요청 속성을 함께 본다. 로그에는 판정과 입증에 필요한 최소 필드만 두고, 로그의 접근·보존·삭제 권한은 서로 나눈다. 비상권한에는 발급 사유와 만료, 사용기록, 사후검토가 있어야 한다. 그래야 비상권한이 정상 권한을 영구히 우회하는 통로가 되지 않는다.
실무 사례: 급여 변경 요청을 끝까지 추적하기
급여 담당자 A가 직원 B의 계좌를 변경한다고 하자. A가 사번을 입력한 것은 식별이고, 비밀번호와 등록 장치로 증명한 것은 인증이다. 이어서 시스템은 A의 담당조직과 계좌 변경 행위, B의 소속, 승인시간과 분리승인 조건을 정책에 대입해 인가한다. 허용됐다면 변경 전후 값이 그대로 드러나는 것은 줄이되, 요청자와 승인자, 대상, 정책판본, 시간, 결과는 서로 연결해 기록한다.
시험은 정상적인 성공만 확인하지 않는다. 다른 조직 직원의 변경, 만료된 권한, 승인자와 요청자가 같은 경우를 거부하는지 본다. 화면을 거치지 않은 서버 API 직접호출과 기록 변경 시도도 거부하는지 확인한다. 공용 payroll-admin 계정은 실제 변경자를 추적하기 어렵게 만들므로 채택하지 않고, 개인 식별과 필요한 시간에만 유효한 권한을 사용한다.
이 사례의 교육용 정책 v1은 같은 조직, 유효한 변경권, 요청자와 다른 승인자를 모두 요구한다.
| 요청 속성 | 인가 결정 | 집행·기록 |
|---|---|---|
| A와 B 조직 X, 권한 유효, 승인자 C≠A | 허용 | 변경 후 성공/실패 결과 기록 |
| B 조직 Y | 거부 | 변경 0회, 조직 불일치 기록 |
| 조직 X지만 권한 만료 | 거부 | 변경 0회, 만료 사유 기록 |
| 승인자 A=요청자 A | 거부 | 변경 0회, 분리승인 위반 기록 |
네 행 모두 인증에는 성공할 수 있지만 집행까지 가는 것은 첫 행뿐이다. 그리고 허용된 뒤 저장장애가 나면 “허용·실행 실패”로 남긴다. 허용되었다는 것과 실제로 성공했다는 것은 같은 말이 아니기 때문이다.
시험에서는 무엇을 요구하는가
식별·인증·인가의 차이를 설명하고, 중요정보 변경에서 책임추적성을 확보하는 통제방안을 제시하시오.
차이에는 목적·입력·결과의 비교가 필요하다. 통제방안은 계정정책만 쓰지 말고 등록–인증–인가결정–집행–기록보호–사후검토 흐름을 제시해야 한다. 또 책임추적성은 로그를 얼마나 많이 보유하느냐가 아니라, 특정 행위를 주체·결정 사유·결과와 신뢰할 수 있게 연결하는 성질임을 밝혀야 한다.
풀이 방향과 모범답안 보기
답안 목차
- 식별·인증·인가·책임추적성의 정의
- 질문·증거·정책·결과 비교
- 등록에서 실행기록까지의 통제 흐름
- 공용계정·과도권한·서버 우회·로그변조 실패
- 비상권한·만료·사후검토와 시험증거
답안에 그릴 도식
| 허용 요청의 연결 | 남길 기록·보호 |
|---|---|
| 식별 주장 → 인증수단 검증 | 개인 주체·신뢰 등록정보 |
| 인가 정책결정 → 서버 집행 | 결정 사유·정책판본; 허용 분기만 집행 |
| 집행·거부 → 결과 기록 | 주체·시간·객체·행위·성공/실패/거부 결과 |
| 기록 → 책임추적성 | 변경보호·보존·사후검토 |
허용·거부 분기 그림과 아래 문장을 함께 사용한다. 인가 결정에서 거부된 요청은 서버의 보호행위를 실행하지 않고 거부 결과만 반환하고 기록한다. 즉 위 도식의 서버 집행 화살표는 허용 분기에만 해당한다.
모범답안
식별은 주체가 식별자를 제시해 자신을 주장하는 단계이고, 인증은 그 식별 주장에 연결된 인증수단을 검증하는 과정이다. 인가는 인증된 주체의 객체별 행위를 정책으로 허용하거나 거부하는 과정이다. 책임추적성은 결정과 실제 결과를 주체·시간·결정 사유에 연결해 사후에 입증할 수 있는 성질이다. 이때 계정의 인증수단을 요청자가 통제하는지 확인하는 일과 실제 사람의 신원확인·등록은 구분한다.
중요정보 변경에서는 개인별 계정을 등록하고 행동위험에 맞는 인증을 적용한다. 서버는 주체·객체·행위·시간·속성과 승인조건을 매 요청에 대입해 인가하고, 요청자와 승인자를 필요한 경우 분리한다. 결정과 실행 결과에는 정책판본·대상·시간·성공 여부를 남기고, 기록 자체의 접근과 변경을 보호한다. 공용계정과 화면에만 있는 인가, 만료 없는 비상권한, 변경 가능한 로그를 통제한다. 끝으로 거부·우회·만료·로그변조 사례를 시험해 네 단계가 실제로 연결되는지 검증한다.
한 번에 되찾기
식별은 주장, 인증은 연결된 인증수단의 검증, 인가는 행위 허용 결정이다. 책임추적성은 결정과 실행을 주체·시간·결정 사유에 연결하며, 공용계정과 불완전한 로그는 그 연결을 끊는다.
디지털 인증의 근거
NIST SP 800-63B-4의 인증 보장범위와 생체 사용조건을 참고했다. 이 자료는 온라인 계정의 인증수단 통제 확인과 신원확인을 구분하는 데 사용했으며, 급여 변경 사례의 조직·권한·분리승인 정책을 정한 자료는 아니다.