외로운 Nova의 작업실

정보보안기사 필기 - 14(UNIX 서버 보안) 본문

Certification/정보보안기사

정보보안기사 필기 - 14(UNIX 서버 보안)

Nova_ 2022. 11. 20. 19:34

- UNIX의 구성

- UNIX의 파일 시스템

<디렉터리 구조>

유닉스의 디렉터리는 트리 구조를 가지며 최상위 디렉터리는 루트입니다. 대부분의 UNIX 운영체제는 아래와 같은 시스템 디렉터리 구조를 가지며 각 디렐터리별로 사용용도 또한 유사합니다.

  • / : 최상위 디렉터리입니다.
  • /etc : 시스템의 환경 설정 및 주요 설정 파일을 담고습니다.
  • /dev : 프린터나 터미널 같은 물리적인 장치를 다루기위한 특수 파일을 담고 있습니다.
  • /usr/bin : 기본적으로 실행 가능한 파일을 담고 있습니다.
  • /usr/include : c 언어 라이브러리 헤더 파일이 저장되는 디렉터리입니다.
  • /usr/lib : 기본 프로그램의 모듈을 담고 있습니다.
  • /usr/sbin : 시스템의 관리 명령어가 저장되는 디렉터리 입니다.
  • /home : 사용자 홈 디렉터리가 저장되는 디렉터리입니다.
  • /tmp : 프로그램 실행 설치시 생성되는 임시파일을 담고 있습니다.
  • /var : 시스템 로그가 저장되는 디렉터리 입니다.

<파일 시스템 구조>

파티션에 생성된 파일시스템은 부트 블록, 슈퍼블록, i-node 블록, 데이터 블록의 네가지 영역으로 분리된 자료구조를 갖습니다. 아래는 참고 자료입니다.

  1. 부트 블록(boot block) : 시스템의 부팅 과정에서 필요한 운영체제의 실행 파일정보를 저장하고 있습니다. 
  2. 수퍼 블록(super block) : 파일시스템의 정보를 유지하는 자료구조로 효과적인 파일시스템의 관리를 가능하게합니다. 슈퍼블록에는 파일시스템의 요약정보와 사용하지않는 i-node와 디스크 블록의 위치정보도 포함되어있어 빠른 파일시스템 구축을 도와줍니다.
  3. i-node 블록 : i-node는 유닉스에서 각 파일에 대한 정보를 기억하는 약 120byte 고정된 크기의 구조체입니다. 일반 파일이나 디렉터리 파일의 i-node 블록은 각 파일의 디스크 블록의 위치를 포함하고 있으며, 특수 파일의 i-node 블록은 주변장치를 식별할 수 있는 정보를 가지고 있습니다. 아래는 i-node의 파일에 대한 정보들 입니다.
  • i-node number : 파일시스템 내에서 해당 파일을 식별하기 위한 고유한 식별자
  • 파일타입 : 파일 유형
  • 접근권한 : 파일에대한 접근 권한
  • link count : i-node를 참조하는 링크 개수
  • 소유자 : 파일의 소유자 UID
  • 소유그룹 : 파일의 소유 그룹GID
  • 파일크기 : 파일의 크기
  • MAC Time : 마지막으로 수정한 시간, 마지막으로 접근한 시간, 파일의 속성을 마지막으로 변경한 시간
  • Block index : data blocks에 저장되어있는 파일 내용에 대한 색인정보

4. 데이터블록(data block) : 실제 데이터들이 저장되어 있습니다.

 

- 디렉터리 정보 출력

문법 : ls [-ailFR] [file_name| directory_name]

  • a : 도트 파일을 포함하여 디렉터리 내에 있는 모든 디렉터리 및 파일을 보여줍니다.
  • i : 디렉터리 및 파일에 지정된 i-node 번호를 보여줍니다.
  • l : 목록 형태로 디렉터리 및 파일의 정보를 자세히 보여줍니다.
  • F : 디렉터리인지 어떤 종류의 파일인지 알려줍니다.(디렉터리 /, 실행파일 *)
  • R : 하위 디렉터리에 있는 내용까지 보여줍니다.

 

- 접근 권한

  • r(4) : 파일을 읽거나 복사할 수 있으며 ls 명령으로 디렉터리 목록을 볼 수 있습니다.
  • w(2) : 파일을 수정, 이동, 삭제 할 수 있습니다.
  • x(1) : 파일을 실행할 수 있으며 파일을 디렉터리로 이동하거나 복사할 수 있습니다.

일반 파일의 경우 접근 권한으로 666(rw_rw_rw)를, 디렉터리의 경우 접근권한으로 777(rwxrwxrwx)를 기본값으로 취합니다. 디렉터리가 777인 이유는 실행 권한이 없으면 디렉터리 안으로 들어갈 수 없기 때문입니다.

 

- 파일 권한 변경

접근 권한 변경 문법 : chmod [-R] permission file_name | directory_name

  • -R : 하위 디렉터리의 파일의 권한까지 변경합니다.
  • permission : 기호나 8진수로 접근권한을 지정합니다.

ex) chmod o-w file.c, chmod 664 file.c

<접근 권한을 기호로 기술하는 방법>

대상 : u(user), g(group), o(other), a(all)

연산자 : +(추가), -(제거), =(지정)

예시) chmod go-w file.c : group과 other의 w 권한을 제거

chmod a=rw file.c : 모든 사용자에게 rw권한 설정

 

<접근 권한을 숫자로 기술하는 방법>

파일의 접근권한을 세개의 8진수로 기술(r=4, w=2, x=1) 및 자리로 user, group, other 설정

예시) chmod 777 file.c : 모든 사용자에게 rwx권한 설정

chmod 664 file.c : user, group에 rw 권한, other에게 r 권한 설정 

chmod 600 file.c : user에게 rw 권한 설정

 

- 소유권 또는 그룹 변경

소유권 변경 문법 : chown  [-hR] owner file name | directory name

그룹 변경 문법 : chgrp [-hR] group file name | directory name

  • h : 심볼릭 링크 파일 자체의 소유주나 그룹을 변경합니다.
  • R : 하위 디렉터리와 디렉터리 하위의 모든 소유주를 변경합니다.

예시) chown Nova file.c : file.c 파일의 소유쥬를 Nova 로 변경

chgrp Nova file.c : file.c 파일의 소유 그룹을 Nova로 변경 

 

- UNIX의 첫번째 프로세스

  • swapper : 유닉스는 부팅 시간 동안 운영체제에 의해서 PID가 0인 swapper이라는 프로세스를 생성합니다.
  • init : swappe를 생성한 후 즉시 PID1을 가지는 init을 만들기 위해 fork/exec를 실행합니다.
  • pagedaemon : init을 생성한 후 즉시 PID2를 가지는 pagedaemon을 만들기 위해 fork/exec를 실행합니다.

swapper와 pagedaemon은 중요하기때문에 커널 모드에서 영구적으로 실행되며 이들을 커널 프로세스라고 부릅니다. 또한 시스템 내의 모든 다른 프로세스들은 init 프로세스의 자손들이 됩니다.

 

- 프로세스 생성 및 종료와 관련한 두가지 규칙

  1. PID가 0인 프로세스를 제외한 모든 프로세스는 실행 중에 부모 프로세스를 갖게됩니다 : 만약 부모 프로세스가 자식프로세스보다 먼저 종료될 경우 자식프로세스는 PID가 1번인 init 프로세스의 양자로 들어가 init 프로세스가 대리모를 하게됩니다.
  2. 프로세스 종료시 자신을 생성한 부모 프로세스에게 자신의 종료를 알립니다 : 만일 부모프로세스가 자식프로세스의 종료를 확인하지 않았다면 자식프로세스는 좀비 프로세스로 남습니다. 좀비프로세스는 자원을 낭비하지 안지만 고정된 크기의 프로세스 테이블에서 계속 상주하기때문에 많아지면 다른 정상 프로세스를 실행할 수 없게됩니다. 해결방법은 부모프로세스에게 SIGCHLD 시그널을 보내서 정리하게 하거나 부모 프로세스 자체를 종료시켜 init 프로세스가 정리하게 하는 방법이 있습니다.

- UNIX 시스템의 시작과 종료

<시작>

시스템의 INIT은 런 레벨을 옮겨 다니면서 각 레벨 마다의 역할을 수행합니다. 런 레벨이란 시스템의 운영 상태를 숫자 혹은 문자로 표현한 것입니다. 아래는 런 레벨의 의미의 일부입니다.

  • 0 : PROM(programmable read-only memory) 모드
  • S, s: 시스템 싱글 유저 모드
  • 3 : 멀티 유저 모드
  • 5 : 시스템 power off 모드

<시스템 종료>

UNIX 시스템을 종료할때의 주의사항은 다음과 같습니다.

  • 접속중인 사용자에게 시스템의 종료를 공지하여 작업을 마무리하도록 해야합니다.
  • 운영 중인 서비스(프로세스)를 안전하게 종료해야합니다.
  • UNIX는 입출력 효율성을 높이기 위하여 하드디스크의 버퍼를 운영하기때문에 비정상적으로 시스템이 종료되면 버퍼에 있는 데이터가 하드디스크에 반영되지 않음으로 하드디스크를 갱신하여 파일시스템의 무결성을 유지해야합니다. 
  • shutdown 명령은 시스템을 안전하게 종료할때 사용합니다. 

- UNIX 파일시스템 연결

<mount>

보조기억장치에 설치된 파일시스템을 UNIX 시스템이 인식하도록 특정 디렉터리에 논리적으로 연결시켜주는 명령어 입니다. 마운트된 정보는 /etc/mtab 파일에 기록됩니다.

문법 : mount [-a] device mount_point

a : /etc/fstab 파일에 정의된 모든 파일시스템을 마운트 합니다.

예시) mount /dev/cdrom /mnt/cdrom : dev/cdrom 디바이스 파일을 /mnt/cdrom 디렉터리로 마운트합니다.

 

<unmount>

unmount 명령은 이전에 마운트 된 파일시스템의 연결을 해제합니다.

문법 : unmount [-af] [device | mount_point]

  • a : 마운트 된 모든 파일시스템을 언마운트합니다.
  • f : 해당 파일시슷템을 사용하는 프로세스를 강제로 종료하고 파일시스템을 언마운트합니다.

예시) unmount /mnt/cdrom : mnt/cdrom 디렉터리에 연결된 파일시스템의 연결을 끊습니다.

 

- UNIX 정기적 스케줄 관리(cron)

cron 데몬 프로세스는 UNIX 시스템에서 정기적인 작업을 지정시간에 처리하기 위해 사용합니다. 만약 작업이 일괄적으로 한번에 처리해야하고 작업에 대한 요구가 불규칙하지 않은 경우 cron 데몬 프로세스로 처리하는 것이 좋습니다. 사용자가 corntab 명령어로 crontab 파일을 작성하면 cron 데몬 프로세스는 crontab 파일을 읽어서 정의된 내용대로 작업을 처리합니다. cron 데몬 프로세스는 UNIX 시스템에서 기본적으로 지원하는 프로세스이므로 사용자는 crontab 명령으로 작업목록을 정의하는 방법만 이해하면됩니다.

 

<crontab 파일 문법>

  • 필드 1: 분을 0-59 숫자로 기술합니다.
  • 필드 2: 시를 0-23 숫자로 기술합니다.
  • 필드 3 :일을 1-31 숫자로 기술합니다.
  • 필드 4 :월을 1-12 숫자로 기술합니다.
  • 필드 5 : 요일을 0-6숫자로 기술합니다. 0은 일요일입니다.
  • 필드 6 : 작업을 절대 경로로 기술하고 인수도 나열합니다.

ex) 20 6 * * 1-5 /work/hello parm1 : 매월 매일 월~금요일 오전 6시 20분에 /work/hello 명령을 param1 인수와 함께 실행합니다.

10 3 * * * /usr/login : 매일 새벽 3시 10분에 /usr/login 명령어를 실행합니다.

 

<crontab 파일 제어>

crontab 파일은 사용자 계정별로 하나씩 만들어져서 계정을 통해 crontab 파일에 접근합니다. 시스템 관리자인 root는 다른 사용자의 crontab 파일을 수정할수 있지만 일반 사용자는 자신의 crontab 파일만 편집할 수 있습니다.

crontab 명령 문법 : crontab -e | -l | -r [login_name]

  • -e : 파일을 편집합니다.
  • -l : 파일을 출력합니다.
  • -r : 파일을 삭제합니다.

ex) crontab Nova -e  : Nova 계정의 crontab 파일을 수정합니다.

crontab -e : 자신의 계정의 crontab 파일을 수정합니다.

 

- UNIX 사용자의 패스워드 관리

UNIX는 /etc/password 파일에 등록된 사용자 계정마다 정보를 저장해둡니다. 하지만 최근에는 보안을 위해 계정의 패스워드를 root만이 읽을 수 있는 /etc/shadow에 인코딩하여 저장합니다.

 

<password 파일>

UNIX 시스템은 사용자가 계정을 만들때마다 해당 사용자와 관련된 정보를 /etc/password 파일에 저장합니다. password 파리의 각 라인은 개별 사용자에 대한 정보로 이루어져 있으며 구분자[:]를 이용하여 7개의 필드로 구분합니다.

[user_account]:[user_password]:[user_id]:[group_id]:[comment]:[home_directory]:[login_shell]
  • user_account : 사용자 계정 또는 로그인 이름으로, root 계정의 경우에는 원격 접속을 금지하는 것이 보안상 안전합니다.
  • user_password : 리눅스나 예전 버전의 유닉스는 이자리에 비밀번호가 직접 기록되었으나 요즘에는 보안으로 인해 /etc/shadow 파일에 비밀번호가 인코딩되어 저장되어 있습니다. 이경우에는 x로 표시합니다.
  • user_id : 시스템이 사용자마다 부여한 일련번호로 보통 100번이하는 시스템이 사용하고 0번은 시스템 관리자를 나타냅니다.
  • ugroup_id : 사용자가 속한 기본 그룹의 일련번호입니다.
  • comment : 사용자 관련 기타 정보로 일반적으로 사용자 이름을 설정합니다.
  • home_directory : 로그인이 성공한 후에 사용자가 위치할 홈 디렉터리의 절대 경로입니다.
  • login_shell : 로그인 셸의 절대 경로입니다.

<shadow 파일>

패스워드를 암호화하여 /etc/shadow 파일에 저장합니다. 계정별 암호화된 패스워드 정보와 패스워드 에이징정보가 저장되어 있습니다. 패스워드 에이징 정보는 시간의 흐름에 따른 패스워드 관리 정책을 말합니다.

[user_account]:[encrypted_password]:[last_change]
	:[min_days]:[max_days]:[warn_days]:[inactive_days]:[expire_date]
  • user_account : 사용자 계정
  • Encrypted_password: 암호화된 패스워드
  • 형식 : $id$salt$encrypted_password
  • id : 적용된 일방향 해시 알고리즘 id
  • salt : 랜덤한 솔트 값
  • encrypted_password : 암호화된 패스워드
  • last_change : 마지막으로 패스워드를 변경한 날짜
  • min_days : 최소 변경 일수로 이 시간이 지나야지만 패스워드 변경 가능 1일(1주)로 권장합니다.
  • max_days : 최대 변경 일수로 이 시간이 지나면 패스워드를 변경해야합니다. 90일(12주)로 권장합니다.
  • warn_days : 경고일수로 max 필드의 시간이 얼마남지 않음을 알리는 일수를 정합니다.
  • inactive_days : 최대 비활성 일수로 이 기간이 지나도록 로그인을 안했다면 비활성화 됩니다.
  • expire_date : 사용자 계정이 만료되는 날입니다.

- 접근 권한 마스크

시스템 관리자는 /etc/profile에 umast를 설정하여 전체 사용자에게 획일적인 umask 값을 적용하여 사용자가 파일이나 디렉터리를 만들때 가지는 기본적인 권한을 조정할 수 있습니다. 일반적으로 파일을 만들때는 666에서 umask를 빼고 디렉터리의 경우 777에서 umask를 뺍니다.

문법 : umasl [mask]

예시) umask 222 : 파일을 만들때 r 권한만 사용자가 얻습니다.

 

- 권한 상승(SetUID, GetGID)

UID와 GID는 각각 RUID(Real UID)와 RGID(Real GID)라고 불립니다. 하지만 특이하게 유닉스에서 어떤 권한을 가지고 있는가에대한 UID, GID로 EUID(Effective UID)와 EGID(Effective GID)가 있습니다.

  • RUID : 프로세스를 실행시킨 사용자의 UID
  • RGID : 프로세스를 실행시킨 사용자의 GID
  • EUID : 프로세스가 실행중인 동안에만 부여되는 UID로 자원에대한 접근을 판단하기 위한 UID
  • EGID : 프로세스가 실행중인 동안에만 부여되는 GID로 자원에대한 접근을 판단하기 위한 GID

일반적인 프로그램을 실행할때는 RUID와 EUID는 같지만, SetUID 비트를 가진 프로그램을 실행했을때만 프로세스 안에서 잠시 일치하지 않는 상태가 발생합니다. 보통 SetUID가 설정되어 있다면 권한이 프로그램을 실행한 사용자의 권한이 아닌 프로그램의 소유주의 권한으로 변경됩니다. 따라서 시스템 관리자는 주기적으로 SetUID가 설정된 프로그램을 확인할 필요가 있으며, SetUID가 설정된 파일은 모두 해킹 대상이 되므로 목록화 하여 관리하는 작업이 필요합니다. EGID는 SetGID로 소유주의 그룹 권한을 갖게됩니다. 아래는 SetUID를 이용한 bash셀 획득 코드입니다.

#include <stdio.h>

main(){
    setuid(0);
    setgid(0);
    system("/bin/bash");
}

SetUID와 SetGID는ls -l 명령어로 확인이 가능합니다. 아래는 ls -l /usr/bin/profile 명령어의 출력 값입니다.

-r-sr-sr-x	1	root	sys		2440	2020년1월1일	/usr/bin/profile

위에서 첫번째 -sr의 s기호는 SetUID를 의미하고 두번째 s 기호는 SetGID를 의미합니다.

 

<SetUID, SetGID 권한 변경 방법>

구분 기호방식 8진수 방식 특수권한설정
setuid(4) s 4000 chmod 4777 a.out
chmod u+s a.out
setgid(2) s 2000 chmod 2777 a.out
chmod g+s a.out

 

- 디렉터리 접근 권한(sticky-bit)

UNIX 시스템에서 sticky-bit를 이용하여 특별한 접근권한을 부여할 수 있습니다. sticky-bit가 설정된 디렉터리는 시스템에 있는 모든 사용자가 파일이나 하위 디렉터리를 생성할 수 있찌만 해당 디렉터리를 지우는 것은 소유주나 root인 경우에만 가능합니다. 그래서 sticky-bit를 공유모드라고 합니다. 아래는 종류에따른 기호와 쓰이는 방법의 예시입니다.

구분 기호방식 8진수 방식 특수권한설정
sticky-bit(1) t 1000 chmod 1777 /nova
chmod o+t /nova
chmod u+t /nova

- 슈퍼 서버(inetd 데몬)

UNIX 시스템에는 다양한 종류의 서버프로그램이 실행되고 있습니다. 예를 들어 텔넷 서버, FTP 서버등이 있습니다. 이러한 개별서버를 하나로 통합하여 클라이언트로부터 서비스 요청이 올때마다 해당 서비스와 관련된 실행 모듈을 실행해주는 서버거 inetd데몬 서버입니다. 시스템에서 불필요한 서비스를 제한하려면 /etc/inetd.conf 파일에서 #으로 주석처리 함으로써 제한이 가능합니다. 

 

<inetd.conf 파일>

inetd.conf 파일에는 7개의 필드가 있습니다. 아래는 필드의 예시 및 설명입니다.

telnet    stream    tcp6    nowait    root    /usr/sbin/in.telnetd    in.telneted

1. 서비스(telnet) : 서비스 이름을 정의하는 것으로 etc/services에 정의되어 있어야합니다.

2. 소켓 타입(stream) : 해당 서비스에대한 소켓유형으로 TCP일경우 stream, UDP일 경우 dgram으로 표기합니다.

3. 프로토콜(tcp6) : /etc/protocols에 정의된 프로토콜 종류와 번호입니다.

4. 대기 설정(nowait) : inetd가 서비스요청을 받은 후에 바로 요청을 처리할 것인지 여부에따라 nowait과 wait으로 구분합니다. TCP는 반드시 nowait이여합니다.

5. 로그인 이름(root) : 데몬을 어떤 사용자의 권한으로 수행할 것인지 명시합니다. 이는 보안에서 매우 중요한데 버퍼 오버플로우와 같이 해킹 공격에 취약하다면 절대로 root 권한을 주면 안됩니다. http는 nobody 권한으로 실행야합니다.

6. 서버(/usr/sbin/in.telnetd) : 해당 서비스를 수행하기위해 어떤 프로그램을 실행할지 절대경로를 적습니다.

7. 인자(in.telneted) : 데몬을 실행하는데 필요한 인자값을 적습니다.

 

<standalone>

standalone 서비스는 inetd 데몬 서버를 통하지않고 독립적으로 실행되는 서비스 데몬을 말합니다. 항상 메모리에 상주해 있으며 자체 설정파일에 의해 접근제어를 할 수 있습니다. 예를들어 httpd, sendmail, named 서비스등이 있습니다.

 

- 접근 통제(TCPWrapper)

TCPWrapper은 클라이언트의 IP주소를 확인하여 접근을 허용한 호스트들에대해서만 서비스를 허용합니다. TCPwrapper가 설치되면, inetd 데몬은 TCPWrapper 데몬인 tcpd 데몬에 연결을 넘겨 호스트의 ip를 검사하고, 허용이 된다면 해당 서비스 데몬에 연결을 넘겨줍니다. TCPWrapper은 모든 프로토콜에대한 접근 제어를 할 수 없습니다. standalone 서비스에대해 접근제어가 되지 않으며 TCP외의 일부 프로토콜에대해서만 통제가 가능합니다. TCPWrapper를 사용하게되면 /etc/inetd.conf 파일의 구조는 실행경로가 usr/sbin/tcpd로 변경하게됩니다.

변경전 : telnet    stream    tcp6    nowait    root    /usr/sbin/in.telnetd    in.telneted
변경후 : telnet    stream    tcp6    nowait    root    /usr/sbin/tcpd    in.telneted

 

<hosts.allow와 host.deny>

TCPWrapper은 /etc/host.allow와 /etc/host.deny 파일에 정의된 호스트 정보를 기준으로 접근 허용 및 금지를 판단합니다. host.allow에 있다면 접근 허용이고 host.deny에 있다면 접근 금지입니다. allow -> deny순으로 읽으며, 만약 설정사항에 포함되어 있지 않는 ip라면 접근을 허용하게됩니다. 아래는 host.allow와 host.deny 파일의 구문 형식입니다.

구문 형식 : service_list: client_list [:shell_command]

  • service_list: 서비스명입니다.
  • client_list: ip입니다.
  • shell_command : 일치하는 것이 있을때 tcpd가 실행하는 셸 명령어입니다.

예시) 아래는 host.allow 파일의 예시입니다.

ALL: 192.168.1.1 = 192.168.1.1은 모든 서비스이용이 가능합니다.

in.telnetd: 192.168.1.1 = 192.168.1.1 은 telnet서비스가 가능합니다.

ALL ACEPT in.telnetd: ALL: = telnet서비스를 제외한 모든 서비스를 모든 ip에서 이용가능합니다.

ALL: LOCAL = 같은 네트워크에 있는 모든 호스트들에게 모든 서비스가 이용 가능합니다.

 

- PAM(pluggable authentication modules, 장착형 인증 모듈)

PAM은 리눅스 배포판에서 사용자 인증의 핵시이며, 각 응용프로그램이 수정없이 PAM을 추가하여 인증형태, 사용자권한, 접근자원등을 선택할 수 있는 라이브러리입니다. 

 

<PAM을 사용한 인증절차>

1. 각 프로그램은 인증이 필요한 부분에 PAM 라이브러리를 호출합니다.

2. PAM 라이브러리가 호출되면 해당 프로그램의 PAM 설정파일을 참조하여 등록된 여러 PAM 모듈을 수행하고 그결과를 응용 프로그램에 반환합니다.

3. 응용 프로그램은 그 반환된 결과를 이용하여 인증여부를 결정합니다.

 

<PAM 설정 파일>

설정 형식 : type    control    module-path    module-argument
  • type : 모듈의 종류로 아래는 종류들입니다.
  • account : 사용자의 시스템 사용권한을 확인하는 모듈
  • auth : 실질적인 인증기능, 패스워드 확인을 담당하는 모듈
  • password: 패스워드를 설정하거나 확인하는데 사용하는 모듈
  • session : 사용자가 인증 성공시 세션을 맺어주는 모듈
  • control : 각 모듈 실행후 성공 또는 실패에따른 PAM라이브러리 행동 결정
  • requisite : 모듈 실행에 실패하면 바로인증을 거부하여 응용프로그램에 거부를 통지합니다.
  • required : 모듈 실행에 실패하더라도 즉시 인증을 거부하지않고 동일 유형 모듈을 실행하고 완료하여 마지막에 인증 결과를 통지하여 사용자가 어느 단계에서 인증을 실패했는지 알 수 없게합니다.
  • optional : 모듈의 성공, 실패 응답을 상관안합니다. 이는 사용하지 않습니다.
Comments