'전체 보기'에 해당되는 글 90건

1. Rainbow Table attack

답지를 들고 있단다.

앞서 비밀번호는 대부분 해시함수를 사용하여 그 결과 값을 데이터베이스에 저장한다고 했다. 따라서 복호화가 불가능한 상태라 평문(비밀번호)의 내용을 관리자한테까지 숨길 수 있는 장점을 가지고 있다. 이에 따라 공격자들은 사전에 해쉬함수에 입력한 값과 해쉬 결과 값을 저장한 일종의 정답지(Rainbow Table)를 가지고 비밀번호를 확인 할 수 있게 되었다. 이런 공격 우연하게 같은 비밀번호를 사용하는 경우에 여러 계정이 동시에 피해를 볼 수 있는 단점이 있다. 따라서 이 공격에 대안으로 Salted hash가 등장하였다.

2. Salted hashed

양념을 촵촵촵

기존에는 패스워드만 해시함수에 통과시켰으나 최근에는 가입 시간이나 난수(Random Number)를 비밀번호와 같이 해시 값에 포함한다. 이 때 추가적으로 포함된 가입 시간이나 난수를 Salt라고 한다. 치킨에다가 양념을 어떤 것을 사용하냐에 따라 맛이 달라지 듯이 서로 다른 계정이 같은 비밀번호를 사용하더라도 Salt가 다르면 완전 다른 해시 값이 달라지며, 설령 같은 해시 값을 같더라 하여도 Salt 값이 전혀 다르기 때문에 평문을 유추하기 힘들다. 이 Salt는 해쉬 결과 또는 Salt 평문을 패스워드 관리 테이블에 같이 보관한다.

Salted hash의 경우 Salt의 길이가 길면 길수록 무차별 대입공격이 강력하다. OpenBSD는 Blowfish라는 블록 암호화 기법을 가지고 있으며 128bit의 Salt를 사용하여 192비트의 해시 값을 만들어 낸다.

시간을 끌자

해시 함수는 암호화보다 소요하는 시간이 짧다. 따라서 암호문을 무차별 대입으로 푸는 것보다 해시함수에 무차별로 대입하는 것이 소모하는 시간이 짧아 이 시간을 늘려야 할 필요성이 있다. 이에 따라 개발자들은 해시함수를 1000번이상 반복으로 실행하여 고의적으로 시간을 늦추려 하고 있다. 

3. Bloom Filter

사용자 교육의 한계

뉴스에서 보안 사고가 발생하여도, 청개구리 같은 사용자들이 많다. 비밀번호를 길고 자연어 사용을 제한하고 취약한 비밀번호 사용을 금지해도 외우기 귀찮고 손에 안 익는 비밀번호를 사용하기 싫어서 무시하고 사용하며, 일정 주기마다 비밀번호를 변경하라는 메세지가 뜨면 "다음에 할게요~ㅎㅎ" 하고 그냥 넘어가 버리는 경우도 많다. 따라서 말 안듣는 사용자를 교육시키기보다 애시당초 시스템에서 보안이 취약한 비밀번호에 대하여 거절을 하게 만든다.

너만 갖고 있냐?? 나도 갖고 있어!!

Brute Force Attack

무차별 대입 공격은 사용자가 입력할 수 있는 모든 글자에 대하여 하나하나 대입을 하면서 비밀번호를 풀어 내는 방법이다. 예전에 여자친구가 아이폰 백업 비밀번호를 잃어 버린적이 있어서 풀어주기 위해 툴을 사용한 적이 있는데 대부분의 툴들은 무차별 대입공격을 기반으로 한다. 특수문자와 영어 대소문자, 숫자로 구성된 비밀번호 9자리를 푸는데 요구되는 시간이 1030년이라고 뜬 적이 있다. 이처럼 무차별 대입공격에 강한 비밀번호가 되기 위해서는 비밀번호를 길고 복잡하게 만들어야 할 필요가 있다. 최근에는 빠른 연산이 가능한 GPU와 멀티 쓰레드처럼 병렬처리를 사용하여 시간을 단축하는 기법도 사용한다.

Dictionary Attack

비밀번호 크랙툴 중에 기본적으로 사전 공격이 있는 툴도 있는데. 공격자가 무차별 대입 공격에서 시간이 많이 걸리는 점을 우회하기 위해서 착안한 방법이다. 이 사전 공격은 공격자가 대부분의 사람들은 자연어를 이용하여 비밀번호를 만든다는 점과 사람들이 자주 사용하는 비밀번호 정보를 수집하여 사전으로 만들고 그 사전의 단어를 기반으로 대입을 하여 비밀번호를 푸는 방법을 말한다. 이 방법을 사용하면 무차별 대입공격보다 한참 적은 시도로 비밀번호를 크랙할 수 있는 장점이 있다. 

Rainbow Table Attack

비밀번호는 대부분 암호화 해시 함수를 사용한 결과 값을 데이터베이스에 저장이 된다. 해시 함수는 일방향 함수로 암호화 과정만 있고 복호화 과정이 없는 특징이 있어서 해당 값을 복호화하는 것은 불가능하다. 하지만 공격자가 해시함수에 다양한 값을 입력하여 얻은 해시 값들을 정리해놓은 테이블(Rainbow Table)이 있다면 해당 데이터 베이스에서 비밀번호를 알아 낼 수도 있다. 또한 우연하게 같은 비밀번호를 사용하는 사람들이 있다면 데이터 베이스에 저장된 해시 값이 같으므로 하나의 비밀번호를 크랙하는 동시에 여러 계정이 폭발하는 문제도 발생할 수 있다.

Exploiting multiple password use

워낙 많은 사이트와 SNS가 있다보니 같은 아이디에 같은 패스워드를 사용하는 경우가 많다. 따라서 만약 하나의 사이트의 아이디, 패스워드가 크랙이 되면 연쇄적으로 다른 사이트도 피해를 볼 수 있다. 가급적 비밀번호를 사이트 마다 다른 것을 쓰는 것을 권장하는 이유다.  

Workstation hijacking

PC방에서 컴퓨터를 켜놓고 잠깐 자리를 비운사이 아직 로그인되어 있는 사이트에 공격자가 앉아서 공격을 하는 방법. 

(좀 성격 안 좋은 형님들이 동생들이 자리 비운 사이에 아이템을 다 팔아버리거나 버려버리는...)

자리를 비우는 경우에는 화면보호기나 컴퓨터를 끄고 가는 것이 좋다.

Exploiting User Mistake

간혹 로그인할 때 아이디를 입력하는 곳에 비밀번호를 입력하여 로그인 버튼을 누르는 경우가 있는데, 로그나 암호화 되지 않은 패킷을 캡쳐하여 비밀번호를 획득할 수 있다. 

보안 카드의 번호를 전부 다 입력하라, 주민등록번호를 말해달라, 비밀번호를 말해달라 등 컴퓨터적인 기술을 이용한 것이 아니라 사회 공학적인 요소를 활용하여 상대방을 속여서 비밀번호 등을 획득하는 방법. 때로는 카페이나 도서관 등에서 대화하는 내용을 수집하여 개인정보를 획득하고 비밀번호를 얻는 방법도 있다.  

1. 필요성

사용자 식별의 필요성

회원가입 과정을 생각해보면 ID 중복 체크를 반드시하여 중복되는 ID에 대한 사용을 금지하는 과정을 쉽게 볼 수 있을 것이다. 왜냐하면 멀티 유저 시스템에서는 각각 유저들에 대한 권한이 다르게 설정되어 있기 때문에 사용자간의 식별을 위해서 중복을 피한다. 예전에는 영문과 숫자 조합의 아이디를 사용하였지만 최근에는 이메일이나 휴대전화번호도 중복이 되지 않는 점을 착안하여 아이디로 사용하기도 한다. 

사용자 인증의 필요성

이제 아이디를 정상적으로 만들어 회원가입을 한 후 해당 사이트에 로그인을 하고자 한다. 아이디를 입력하고 우리는 비밀번호를 입력한다. 비밀번호로 나 자신이 해당 계정의 주인임을 인증하는 것이다. 식별과 비슷한 이유로 사용자 간의 권한은 서로 다르기 때문에 해당 권한을 사용할 사람이 맞는지 아닌지를 입증을 할 필요가 있다. 

2. 인증 방법의 분류

Something you know

당신만이 알 수 있는 내용으로 사용자를 인증하는 방법이다. 대표적으로 Password나 Pin이 있으며, 간혹 비밀번호나 아이디를 찾고자 할 때 "당신이 가장 소중하게 여기는 것은?"이라는 질문을 하는 경우도 해당한다. 

이 방법의 장점은  주인이 분실하거나 유출이 의심될 때 쉽게 비밀번호를 변경을 할 수 있다는 점이다. 그에 반해 단점은 본인이 아닌 다른 사람이 해당 비밀번호를 알고 있다면 쉽게 접속하여 권한을 남용하여 시스템에 해를 입힐 수 있다. 따라서 비밀번호를 인증으로 사용하는 경우에는 저장할 때 암호화 해시를 사용하는 등 비밀번호의 보관에 신경을 더욱 쓸 필요가 있다.

Something you have

은행에서 공인 인증서를 발급 받으면 보안카드나 OTP를 발급 받을 수 있다. 또는 회사에 입사하면 사원증을 발급 받는데 그것을 이용하면 회사의 입구에 카드를 대어 사원을 인증하는 경우도 본 적이 있을 것이다. 

이처럼 개인이 가지고 있는 것으로 인증을 하는 방법도 있다. 이 방법은 해당 기기를 분실 / 도난 당하지 않는다면 안전하게 개인을 인증할 수 있는 장점이 있다.

Something you are

요즘 최신 스마트폰에 내장된 지문 / 홍채 인식처럼 생채정보를 활용하여 인증을 하는 방식이다. 사용자만이 가질 수 있는 것을 이용하기 때문에 해당 사용자만이 사용할 수 있는 장점이 있어 강력하지만 만약 유출이 되어진다면 변경이 불가능하다. 일반적으로 홍채의 경우가 가장 정확성이 뛰어나지만 비용적으로 아직 비싼 기술이다.

바이오 인증 과정은 우선 사용자는 자신의 신체 특징(지문, 홍채)을 입력하면 컴퓨터에서 특징점을 분석하여 데이터베이스에 저장한다. 사용자는 인증이 필요한 경우 해당 인식기에 자기의 지문, 홍채 등을 입력하면 데이터 베이스에 저장된 특징점과 입력된 특징점을 비교하여 해당사람이 맞는지 아닌지를 인증한다. 수사와 같이 특수한 경우에는 데이터 베이스에 범죄자로 추정되는 지문을 입력하여 특징점과 데이터베이스 내부의 모든 데이터와 특징점과 비교하여 해당 사람이 누구인지를 확인하는 절차를 가진다.

Something you are/not

최근에 나의 페이스북이 내가 사는 곳이 아닌 엉뚱한 곳에서 접속을 한 이력이 있다고 페이스북에서 경고메세지를 보내 주었다. IP나 Mac Address로 평소에 접속하는 곳이 아닌 엉뚱한 곳에서 접속하는 경우 당신이 맞는지 아닌지 확인을 해주는 기능이 페이스북에 있었나보다.. 이처럼 사용자의 Mac 주소나 IP 주소로도 인증이 가능하며 이 경우는 이동이 잦은 경우에는 IP주소가 달라지고 다양한 기기를 사용하면 Mac 주소의 변별력이 떨어지므로 이동을 하지 않거나 해당 디바이스가 고정된 경우에 사용하는 것이 좋다.

3. 스마트 카드

Memory 카드

Memory 카드는 데이터를 저장할 수는 있지만 연산이 불가능한 카드다. 일반적으로 카드의 자기선이나 내부의 메모리 칩에 데이터를 저장되어 있으며 카드를 사용할 때 비밀번호를 입력하는 것으로 보안을 강화한다. 우리가 은행에서 사용하는 신용카드가 이와 같은 형태를 가지고 있으며 비밀번호 4자리를 사용하는 대신 입력의 횟수를 제한하여 무차별 대입 공격을 방지한다.

스마트 토큰(OTP)

데이터의 저장 뿐만 아니라 마이크로프로세서가 내장되어 있어 연산이 가능하다. 일반적으로 키패드와 함께 있어 키패드로 비밀번호를 입력하면 내부 연산으로 One Time Password(OTP)를 생성하여 디스플레이에 보여준다. OTP는 임시적인 비밀번호로 한번 사용하게 되면 Dynamic Password Generator에 의해 새로운 일회용 비밀번호를 생성하는 방법인 Challenge-response를 사용한다. 

스마트 카드

스마트 토큰의 기능과 메모리 카드의 기능을 한 카드에 모은 것이 스마트 카드이다. 메모리가 있어서 데이터를 저장할 수 있으며 프로세서가 있어서 연산에 가능하며 입출력장치도 가지고 있다. 메모리는 카드의 유통기한동안 바뀌지 않는 데이터를 저장하는 ROM, 어플리케이션 데이터와 프로그램을 가지고 있는 EEPROM, 어플리케이션이 수행할때 임시적으로 데이터를 생성하는 RAM을 가지고 있다.

1. Buffer Management

Buffer Management의 역할

사용자가 어떤 쿼리문을 요청하면 DB에서 해당 내용을 메인 메모리의 버퍼 풀에 저장하여 사용한다. 요청한 페이지가 버퍼 풀에 없다면 한 프레임을 대체하여 사용하며 대체되는 프레임이 변경(dirty)되었다면 해당 내용을 디스크 상에도 반영을 하여 준다. 만약 순차적인 스캔 등 다음에 읽을 페이지가 예상이 가능하다면 미리 여러 개의 페이지를 메모리 상에 올려 주는 것이 효과적이다. 

Buffer Replacement Policy

LRU, MRU, Clock 등등 다양한 교체 알고리즘으로 정책을 세우되 접근 패턴을 고려하여 선택을 해야한다. 만약 버퍼 프레임보다 페이지의 수가 많다면 Sequential flooding이 발생한다. LRU를 사용하면 I/O하는 시간이 많이 소비되어 이 경우에는 MRU가 비교적 효과적인 알고리즘이 된다. 

2. InnoDB record format

Variable Length

한 필드의 타입이 int(4)라면 int형 데이터를 무조건 4개를 넣어라는 것이 아니라 4개 이하의 데이터를 넣을 수 있으며 not null 조건이 없다면 null도 허용된다. 이처럼 데이터 필드의 크기가 변화가능한(variable) InnoDB의 데이터 필드를 저장할 때 각각의 필드의 시작지점을 저장하는 Field Start offset을 함께 저장한다.

Record format

우선 가장 앞의 Field start offset은 각각의 칼럼의 시작 위치를 저장하는 곳이며 Extra Byte 구간을 기준으로 좌우 대칭된 모습으로 저장한다. 대게 1Byte를 사용하며 가장 첫 비트는 null여부를 판단하는 비트로 사용한다. 예를 들어 F3가 1000 0001이라면 해당 데이터 필드는 null이다. 따라서 표현가능한 크기는 127이하를 표기 가능하며 만약 127이상의 데이터 필드가 있다면 1 바이트를 추가적으로 사용하여 표기가능하다. 두 바이트를 사용하는 경우에는 첫 비트는 null여부, 두 번째 비트는 같은 페이지에 데이터가 있는지 여부를 표기한다. 왜나햐면 크기를 나타내는 비트의 수가 14개이므로 최대 16,383byte를 표현 가능하므로 같은 필드의 데이터가 다른 페이지 상에 존재할 가능성이 있기 때문이다.

Extra Byte는 Field start offset이 1바이트인지 2바이트인지, 다음 레코드의 포인터값 등등을 저장하는 필드이다. InnoDB에서는 6바이트를 사용하여 정보를 표기한다.

System Column에는 해당 rowID(S1), 트렌젝션ID(S2), Rollback pointer(S3)를 담고 있으며 해당 크기는 각각 6바이트,  6바이트, 7바이트이다. Rollback pointer의 경우 트렌젝션 수행 중에 만일 Rollback을 하게 되면 해당데이터가 원상 복구되어야하는데 변경 전의 데이터를 가지고 있는 필드를 가리키는 포인터로 사용한다.

캐시와 성능

CPU에서 캐시로 접근하는 시간을 Tc, 메인 메모리에 접근하는 시간을 Tm이라고 하였을 때 

1) 캐시가 없는 경우 : Tm

2) 캐시가 있는 경우 : T = h x Tc + ( 1 - h )(Tm + Tc) = Tc + (1-h) Tm 으로 각각 표현이 가능하다. 

여기서 h는 hit ratio(적중률)로 CPU가 요청한 내용을 캐시 메모리가 가지고 있을 확률을 의미한다.

일반적으로 Tc와 Tm을 비교하면 10배이상 차이가 나므로 적중률을 높여서 전체 시간중에 메모리에 있는 시간을 줄여야한다. 

라인의 크기를 키우자

이미 데이터의 지역성을 통하여, 보통 원하는 Word외에 인접한 데이터까지 한꺼번에 가져와서 미리 준비를 하여 성능 향상을 노린다는 점이다.  처음에는 이 논리에 의하여 성능이 향상되지만 어느 정도 크기가 커지면 적중률이 오히려 떨어지는 현상이 발생한다. 캐시 내에 가져온 데이터를 재사용하기 전에 다른 데이터를 가져오기 위해서 캐시에서 제거해야 하기 때문이다.

다단계 캐시

회로의 밀도가 높아짐에 따라 캐시를 프로세서 안에 두는 것이 가능해졌다. 기존에는 공용 선인 버스를 활용하여 데이터를 주고 받았지만 이제 하나의 칩 안에서 프로세서와 공존하므로 버스를 사용할 필요가 없어 졌다. 따라서 캐시와 프로세서간의 데이터가 오가는 동안 버스는 다른 전송을 할 수 있어지고 캐시는 버스를 기다릴 필요가 없어져서 시스템의 성능을 향상시킬 수 있다. 보통 3단계 캐시를 사용하고 L1, L2 캐시는 내부에 L3 캐시는 외부에 존재한다. 이들을 사용하여 효율을 볼려면 L1, L2의 적중률이 달려있다.

분리 캐시

기존의 캐시는 명령어와 Data를 구별하지 않고 무조건 저장하는 통합 캐시를 사용하였으나 명령어 패치와 데이터 패치 사이에 경쟁이 발생하는 것을 줄이기 위해 L1캐시의 경우 Data와 명령어를 분리하는 캐시를 사용한다.  이는 CPI(Clock cycle Per Instruction)를 파이프라인을 통해 줄여서 컴퓨터의 성능을 높혀준다. 

1. 교체 알고리즘

필요성

직접 매핑하는 경우에는 라인 별로 들어 갈 수 있는 곳이 정해져서 필요하지 않지만 연관, 세트연관 매핑의 경우 임의로 블록이 들어가기 때문에 교체 알고리즘이 필요하다. 그리고 이 교체하는 과정을 빠르게 하기 위해 알고리즘이 하드웨어로 구현되어야 한다.

대표적인 알고리즘

1) LRU(Least Recently Used) : 캐시 내에서 가장 오랫동안 참조되지 않은 블록을 교체하는 방식으로 

                                         구현이 단순하여 가장 널리 사용되는 알고리즘

2) FIFO(First In First Out) : 캐시 내에서 가장 오랫동안 있던 블록을 먼저 교체하는 방식

3) LFU(Least Frequency Used) : 가장 적게 참조되었던 블록을 교체하는 알고리즘

 2. 쓰기 정책

필요성

캐시는 프로그램 속도를 빠르게 하기 위한 운송업체 같은 역할일 뿐 실제 프로그램은 메인 메모리에서 수행한다. 따라서 캐시의 데이터가 변화하면 메인 메모리에도 똑같이 반영이 되어야 프로그램을 완벽하게 수행할 수 있으므로 캐시의 내용을 메모리에 다시 반영하는 쓰기 정책이 필요하다.

Write Through

가장 간단한 기법으로 캐시에 생기는 변화가 즉각적으로 메인 메모리에 반영이 되어지는 것이다. 하지만 메인 메모리의 사용량이 증가하여 병목현상이 발생할 수 있다.

Write back

위의 방법을 보완하는 방법으로 캐시 내의 데이터만 갱신이 되고 메모리는 나중에 캐시에서 데이터를 다시 가져오는 과정에서 갱신이 되는 점이다. 따라서 캐시의 데이터와 메모리의 데이터가 서로 달라지는 모습을 자주 보이는데 이 상태를 Dirty, 더럽혀 졌다고 한다.  속도는 개선되는 방면에 회로가 복잡하고 디바이스를 제어하는 경우 캐시의 내용을 디바이스로 전달을 안하는 경우가 간혹 발생한다.

1. 암호화

암호화의 목적

암호화는 정보 노출(information disclosure)를 막기 위한 도구로 사용한다. 사용자는 프로그램이나 인터넷을 통하여 다양한 데이터를 주고 받는다. 이 과정을 그냥 평문으로 작성되면 도청을 하는 제3자에 의해 악용될 가능성이 있다. 따라서 암호화를 하여 키를 가지고 있지 않은 제 3자가 중간에서 도청을 하더라도 평문의 내용을 알 수 없고 키를 가지고 있는 대상에게만 평문의 내용을 확인하기 위해 암호화 기법을 사용한다. 

암호의 역사

암호화의 역사는 고대 로마시대의 카이사르 암호에서 시작한다. 평문의 글자의 위치를 바꿔가면서 키를 가지고 있지 않은 사람에게는 평문의 내용을 쉽게 알 수 없게 한다. 하지만 키의 크기가 작아서 무차별 대입공격에 취약하고 영어 문자의 특징상 자주 쓰는 알파벳이 있어서 사전 공격에 취약하다는 단점이 있었다.  시간이 지나 조금 더 발전된 암호가 Vigenere cipher다. 키가 되는 문자와 평문의 한 글자씩 사전에 준비한 표를 통하여 바꿔나가는 방법이다. 

대칭키 / 비대칭키

대칭키는 송신자와 수신자가 동일한 키를 가지고 있다. 따라서 암호화와 복호화를 같은 키를 통하여 수행한다. 속도적인 측면에서 비대칭키보다 매우 뛰어나지만 키를 어떻게 분배를 할 것인가에 대한 문제가 있다. 

비대칭키는 송신자와 수신자가 서로 다른 키를 가지고 있어 암호화와 복호화의 키가 서로 다르다는 특징이 있다. 이 알고리즘에서 수신자는 개인 키(private key)는 자신이 가진 채 비밀로 하고 공개 키(public key)를 인증 센터에 등록한다. 그리하여 송신자는 수신자의 공개 키로 암호화하여 수신자에게 전송하면 수신자는 개인 키로 복호화하여 원문을 확인 할 수 있다. 따라서 개인 키를 모르는 공격자는 해당 내용을 알 수 없다.  

키 분배를 해결할 수 있다는 점에서는 우수하지만 속도가 느려 현재는 비대칭키 알고리즘으로 대칭키의 키 분배를 한 후 대칭키 알고리즘을 통하여 통신을 한다. 대표적인 알고리즘으로 대칭키는 DES 알고리즘, 비대칭키는 AES 알고리즘이 있다. 

2. 해시 함수

해시의 목적과 특징

해시는 데이터 변조를 막기 위한 조치로 만들어진 기법이다. 해시는 입력의 크기와 상관없이 일정한 길이의 출력 값을 출력하는 것이 특징이고 한 글자라도 변조가 발생하면 해시 값 전체가 변화하는 특징이 있다. 이러한 특징으로 중간에 데이터 변조가 발생하였는지 여부를 확인할 수 있다. 대표적인 알고리즘으로 SHA 알고리즘이 있다.

암호화 vs 해시함수

해시와 암호화 도구와 큰 차이점은 역함수가 없다는 점. 따라서 복호화를 통하여 평문을 확인할 수 있는 암호화 도구들과는 달리 해시 함수는 복호화를 할 수가 없다는 특징이 있다. 이러한 특징을 잘 볼 수 있는 대표적인 사례가 패스워드 관리다. 비밀번호를 까먹어서 비밀번호 찾기를 누르고 각 종 본인 인증을 끝나면 비밀번호를 알려주는 것이 아니라 새로운 비밀번호를 작성할 것을 요청한다. 왜냐하면 비밀번호 평문을 데이터베이스에 저장한 것이 아니라 해시함수를 거친 결과물을 데이터베이스에 저장해서 관리자도 알 수 없고 복호화 자체를 할 수 없어서 원래 비밀번호가 뭔지 알 수 없기 때문이다.

1. InnoDB

Clustered index

MySQL은 InnoDB에서 작동하는 SQL이다. 그리고 이 InnoDB는 테이블의 기본 키(PK)를 인덱스로 하여 사용하며 동기화 되어 저장한다. 다시 말해 데이터가 변경, 삭제, 삽입이 발생하면 기본 키에 대하여 데이터 레코드를 정렬을 한다. 만약 기본키가 없는 테이블은 not null인 Unique Key를 사용하고 그것마저도 없으면 내부적으로 숨겨진 Row ID를 사용하여 사용하며 새로운 열에 대하여는 단계적으로 증가한 ID값을 넣어 사용한다. 

Secondary index 

InnoDB는 Clustered index를 제외한 나머지 인덱스를 보조 인덱스로 사용한다. 이론적으로 non-clustered index를 사용하면 해당 레코드의 RID(Row ID)로 데이터 레코드에 접근하는데 InnoDB에서는 RID 대신 기본 키 로 대체하여 사용한다. 따라서 기본 키의 크기가 매우 긴 경우에는 보조 인덱스의 크기가 비대해질수도 있으므로 기본키의 크기를 작게 사용하는 것이 좋다.

2. Index Query

index 생성

1. 기본 키 또는 Unique key 선언된 테이블 생성 시 자동으로 생성

2. 기본 키가 없는 테이블에 기본 키를 지정하는 경우

3. 직접 index 생성

Index Hint

DB가 보통 최적의 인덱스를 선택하는 경우도 있지만 인덱스의 선택이 옳지 못한 경우에는 사용자가 직접 인덱스 힌트를 줘서 사용을 강제로 하거나 사용을 못하게 막을 수 있다. 

use : 인덱스를 써 볼 것을 권유... (최적화를 고려하므로 강제성이 없다.)

force : 강제로 인덱스 사용. (Table Scan이 더 효율적인데도 강제적으로 사용한다) 

ignore : 해당 인덱스를 사용을 금지한다.

Index List

해당 테이블에 어떤 인덱스가 있는지 확인할 수 있는 쿼리

1. Workload

인덱스는 양날의 검이다.

탐색 속도를 향상시켜주는 인덱스의 장점이 있지만 잘못된 인덱스의 선택은 오히려 작업량을 늘릴 수 있기 때문에 인덱스의 선택은 상황을 판단하여 신중히 행하여야 한다. 또한 DBMS마다 지원하는 index방식이 다르기 때문에 각각의 DBMS에서 사용하는 방식에 대한 이해가 필수적이다. 

예를 들면 MySQL의 경우 테이블의 기본 키(Primary key)로 자동으로 클러스터화된 인덱스를 생성한다. 

따라서 언클러스터화된 인덱스는 MySQL DBMS에서는 사용이 불가능하다. 

또한 인덱스는 테이블의 갱신 속도를 늦추기 때문에 아무렇게 인덱스를 짜면 안된다. 왜냐하면 인덱스가 정의된 데이터 테이블들은 인덱스에 따라 물리적 또는 논리적으로 정렬을 하기 때문에 삽입, 삭제, 변경이 발생하면 다시 재정렬을 하여야하므로 잦은 입출력이 있는 은행이나 게시물 등에 아무렇게 인덱스를 사용하면 성능을 저하시킬 수 있다. 

2. Clusetered Index

탐색키가 하나인 경우

Clustered index는 테이블에 단 하나만 생성할 수 있으므로 어떤 탐색키를 사용할 지 선택을 신중하게 하여야 한다. 각각의 쿼리와 조건에 따라서 index를 사용한 탐색을 할지 테이블 전체를 스캔할지 선택하여한다.

위의 쿼리에서 E.age를 index로 사용할지 선택하라면 Emp 테이블의 40세 이상의 비율이 어느 정도 인지 확인이 필요하다. 40세 이상의 인원이 적다면 인덱스를 통한 탐색을 매우 유용할수 있다. 하지만 40세 이상의 비율이 대다수이라면 굳이 인덱스를 통한 탐색이 아니라 테이블 전체를 스캔하는 것이 더욱 효율적이다. 왜냐하면 클러스터화된 인덱스의 경우는 모든 데이터 레코드들이 물리적으로 탐색키에 맞게 정렬이 되어 있다. 

위의 쿼리는 각각의 부서별로 사원의 나이가 10세 초과인 사람의 수를 구하는 쿼리다. dno와 age중 어떤 것을 index로 고른다고 한다면 10세 초과의 사원의 수가 전체 데이터에 어느 정도를 차지하는지 알아야할 필요가 있다. 만일 10세이상의 사원이 첫 번째 사례처럼 대다수라면 인덱스로 사용하는 것은 부적절하다. 오히려 dno를 인덱스로 사용한다면 더욱 효율성이 있을 것이다. 데이터들은 dno에 따라 정렬이 되어 있으므로 인덱스를 탐색한 후에 조건에 맞는 것만 세면 되기 때문이다.

두 개 이상의 탐색키 활용

직원의 나이를 나타나는 age와 봉급을 나타나는 sal을 탐색 키로 사용하는 클러스터화된 인덱스가 있다고 하자. 어떤 것을 우선적으로 정렬하는 가에 따라 <age, sal> , <sal, age> 둘 중에 하나를 사용할 수 있다.

1. 만일 age = 30 이고 sal = 4000인 사람을 찾아라 

 <age, sal> 이나 <sal, age> 둘 다 효과적이다. 만일 age 를 단독으로 인덱스로 사용한다면 age가 30인 사람은 금방 찾지만 sal이 4000인 사람은  해당 age 전체를 탐색하여야 한다. 하지만 인덱스로 <age, sal>을 찾는 경우는 모든 데이터 레코드들이 age로 정렬된 후 sal로 정렬하기 때문에 4000인 사람을 쉽게 찾을 수 있다.

2.  age = 30 이고 3000<sal<5000인 직원을 찾아라

<age, sal>이 <sal, age>보다 더욱 효과적이다. age=30를 찾은 다음에 그 후 sal로 정렬된 데이터 레코드를 수평으로 이동하면서 범위 탐색을 할 수 있어서 <age, sal> 가 더 효율적이다.

따라서 <age, sal>, <sal, age>중 선택하는 방법은 둘 중에 어떤 것이 작은 범주에 들어가는냐는 것을 생각을 하고 선택하는 것이 옳다. 

3. Unclustered Index

index-only plan

Unclustered Index의 경우 데이터 엔트리상에 탐색 키로 논리적으로 정렬이 되어있고 데이터 레코드들이 물리적으로 정렬하지 않는다. 따라서 데이터 엔트리에서 데이터 레코드로 직접 탐색하기 전에 데이터 엔트리내에서 찾아서 식별하는 것이 답을 찾아낼 수 있는 적절한 인덱스의 선택이 필요하다.  나머지 인덱스의 사용에 고려할 사항은 위의 클러스터화된 인덱스와 유사하여 생략한다.

1. Overview

Multi-user System

요새는 다 개개인의 책상이 떨어져 있지만 옛날에 초등학교 다닐때 우리학교에는 두 책상이 붙어있는 경우가 있다. 그 경우 꼭 유치하게 넘어오면 내꺼라는 둥하면 티격태격한 기억이 있는 아재들이 있을 것이다. 리눅스도 이 초등학교처럼 하나의 운영체제에서 많은 유저가 사용할 수 있는 운영체제이다. 만일 권한의 경계를 명확하게 하지 않으면 다른 계정에 의해 내가 작업해놓은 파일들이 없어지고 수정되어 있는 참사가 벌어질 수도 있다. 따라서 리눅스는 소유권과 허가권의 개념으로 파일의 읽고 쓰고 접근(실행)하는 권한을 구별한다.

2. Ownership & Permission

소유권(Ownership)

소유권은 파일 또는 디렉터리의 주인이 누구인지 밝히는 것이다. 

1. 리눅스는 파일 또는 디렉터리의 소유권 UID와 GID으로 표기를 한다. 

2. 일반적으로 리눅스 상에 계정을 생성하면 /home/ 안에 계정명과 동일한 디렉터리를 생성한다. 

3. 또한 일반적으로 리눅스의 새로운 계정의 그룹은 계정명과 동일한 그룹에 소속한다.

위의 명령어를 사용하면 파일이나 디렉터리의 소유권을 변경할 수 있다. 

하지만 아무나 변경하면 안되니까 소유권자나 최고 존엄 root 만이 바꿀 수 있다.

허가권(Permission)

허가권은 이 파일 또는 디렉터리에 대해 현재 계정이 어떤 것을 할 수 있는지 보여주는 것이다.

위의 명령어를 사용하면 파일이나 디렉터리의 허가권을 변경할 수 있다. 

하지만 아무나 변경하면 안되니까 소유권자나 최고 존엄 root 만이 바꿀 수 있다.

이 때 권한을 입력하는 방법은 읽기를 4, 쓰기를 2, 접근을 1로 하고 이 수들의 합으로 표현한다.

예를 들면 rwxr-x--x는 751로 표현 가능하다.

3. 특수 권한

SetUID : UID 권한 상승

각각의 프로세스는 Real UID와 Effective UID, Saved UID를 가지고 있다. 실제 프로그램을 수행할 때는 RUID가 아닌 EUID를 사용하여 허가권을 계산한다. 파일의 권한이 SetUID로 설정되어 있으면 일시적으로 상승된 권한을 다시 원래 권한으로 복귀하기 위해 saved UID에 기존의 UID를 저장한 후 Effective UID를 일시적으로 파일의 소유권자의 UID로 변경하여 사용할 수 있다. 일반적으로 SetUID는 실행가능한 파일에 주로 설정한다.

setUID는 권한 상승을 시켜 다른 계정이 사용할 수 없는 프로그램을 일시적으로 사용할 수 있어서 유연성이 있는 권한이지만 취약한 프로그램이 setUID로 설정되어 있다면 쉘코드를 주입하여 남용이 가능하다. 특히 root에 대한 setUID가 악용되면 서버 전체에 큰 피해를 줄 수 있으므로 가급적 사용을 자제하는 것이 좋다.  

SetGID : GID 권한 상승

setGID는 setUID와 비슷하게 권한을 일시적으로 상승시켜주는데 파일 또는 디렉터리의 GID의 권한으로 상승을 시켜준다. 일반적으로 디렉터리나 실행 가능한 파일에 사용하며 디렉터리에 이 권한이 있으면 그 안에서 생성한 새 파일들의 GID는 해당 디렉터리의 GID로 상속받는다.

Sticky bit : 게시판같은 개념

sticky bit는 주로 디렉터리에 사용하여 누구든지와서 파일을 생성할 수 있는 일종의 게시판과 같은 개념이다. 생성된 파일에 대한 삭제권한은 파일의 주인만이 할 수 있다는 점도 게시판과 많이 닮은 부분이다.