KnockKnock

이러한 기능은 주기적으로 조건에 맞는 파일을 생성해야 하는 로그성 작업 또는 백업 파일 생성에 적합하다.

주기적으로 서버에서 어떤 작업을 해야할 때, 서버에서는 Cron / Batch / Event 등을 통하여 주기적인 작업을 진행한다.

DB에서도 주기적으로 작업을 해줘야 하는 것이 있다.

대표적인 것으로는 특정 Event에 따라 별도의 테이블에 데이터를 자동적으로 이관한다거나, 자동으로 데이터 백업을 해야 하는 것 등이 있을 것이다.

Trigger과 같은 기능을 사용해도 유사한 기능을 수행할 수 있으나, Trigger는 어떠한 이벤트가 발생했을 때 사용되는 것이기 때문에, 주기적인 작업에는 적합하지 않다고 볼 수 있다.

또한, DB를 사용하는 서버(Application)에서 주기적으로 쿼리를 DB로 요청할 수도 있다.

하지만 이 경우에는 Application이 비정상 작동 또는 장애가 발생했을 경우가 있을 수 있으므로, 장애 포인트가 하나 늘어난다고 볼 수 있다.

(물론 과거에 MySQL, MariaDB의 Event Scheduler의 성능이 떨어진다는 이야기도 있었으나, 최근에는 많이 개선되었다고 하고, 시스템별로 느슨한 연결을 하기 위하여 DB의 Event Scheduler 사용도 필요하다.)

Event Scheduler 사용 설정

우선, MariaDB에서 별도로 설정하지 않았다면, Event 옵션은 Off 상태이다.

이를 활성화시키기 위해서 두가지 방법 중 하나를 선택하면 된다.

1. Option 변경

2. my.ini  (Linux에서는 my.cnf ) 에 설정 추가

  event_scheduler = ON  

*1번의 경우에는 Event Scheduler 사용을 위해 재시작이 필요없지만, 다음 재시작 때에는 Event Scheduler가 설정값을 따른다 (기본은 Off)

*2번의 경우에는 재시작을 해야만 설정에 추가되며, 한번 재시작 하고 난 다음에는 시작마다 설정이 On 되어 있다.

Event Scheduler 설정 확인

Event Scheduler 등록

Event Scheduler 관리

이전 포스트에서는 MariaDB를 활용한 암호화 하는 방법을 소개했다.

이렇게 생성된 패스워드를 사용하는 방법 중, 시스템 간에 API호출할 때 패스키로 사용할 수 있다.

다시 말해서 파라미터를 전달할 때, 암호화된 키를 같이 전달함으로써 상호간에 인증된 시스템이라는 것을 확인할 수 있다.

단방향 암호화인 경우에는 단순히 해시값을 비교할 수도 있으며,

양방향 암호화인 경우에는 사전에 약속된 암호화Key를 사용하여 복호화하고, 비교해볼 수 있다.

위 두가지 케이스에 대해서 보통은 API를 만들고, 그것을 호출해서 사용한다.

하지만 API를 사용하기 힘든 환경이거나 굳이 API를 위해서 별도의 서비스가 부담스러울 경우에는 DB에서 SP (Stored Procedure)를 호출하여 사용할 수 있다.

Input값에는 암호화에 사용되었던 Parameter들과 암호화된 String이 대입된다.

Output은 암호가 맞는지 틀린지에 대한 Boolean 값이 리턴되며, false는 0으로, true는 1로 표시된다.

아래 예시는 3개의 Parameter를 사용한 MD5 암호화이며, 내부 로직만 바꾸면 다른 암호화로 대체할 수 있다.

3개의 파라미터를 사용하는 SP 생성문

SP 호출 예제 

회사에서 보안이라고 하면 가장 기본적인 것이 데이터 암호화라고 할 수 있다.

이 암호화라는 것이 사용 목적에 따라 다른 방법을 사용해야 한다.

암호화를 크게 구분하자면, 복호화가 가능한지의 여부에 달라진다.

다시 말해서, 암호를 만들었는데, 이를 다시 평문으로 되돌릴 수 있는지에 다르다.

주로 패스워드는 단방향 암호화를 사용한다.

중요하지 않은 정보들은 암호화 하지 않는 경우가 많고, 보안적으로 껄끄럽거나 중요한 정보(개인정보 등)은 양방향 암호화를 한다.

물론, 복호화가 불가능한 알고리즘이라고 하더라도, 알고리즘별로 보안적 이슈가 존재한다.

단순히 생각해서, 모든 암호화 알고리즘을 강력한 것으로 사용하면 좋을까?

당연히 보안성 측면에서는 좋다. 하지만, 실용성에서는 큰 무리가 따른다.

예를 들어, 실시간성이 보장되어야 하며, 높은 TPS (Transaction Per Second)가 요구되는 시스템에서는 강력한 알고리즘을 사용하기에는 큰 비용이 요구된다.

따라서 보안 레벨과 실용성에 맞는 적절한 암호화 적용이 필요하다.

암호화를 실제로 사용하기 위해서는

1. DBMS에서 제공하는 알고리즘 사용

2. (Application 또는 Server Side에서) Library 사용

3. 직접 구현 (올ㅋ)

의 방법이 있을 것이다.

상황별로 차이가 있겠지만, 

1번의 경우에는 데이터 저장,

2번의 경우에는 네트웍 구간에서의 적용이 주된 목적일 것이다.

앞 이야기가 길었는데, 제목과 같이 1번에 해당하는 암호화 방식을 '간단한' 방식으로 소개한다.

1. MD5

SELECT MD5('ABCDE');

허무할 정도로 간단하다.

다음 것도 그렇다.

2. SHA2

SHA256

SELECT SHA2('ABCDE', 256);

SHA 512

SELECT SHA2('ABCDE', 512);

3. AES128

MariaDB에서는 기본적으로 AES128 암호화 방식을 지원한다. Rijndael 이라는 수학자가 제시한 알고리즘을 사용하고 있으므로, Rijndael의 이름을 가진 라이브러리를 사용하는 경우가 많다.

AES도 두가지 종류가 있는데, ECB와 CBC 방식이다.

CBC 방식은 IV (initialization vector)라는 값을 사용한다는 차이가 있다.

(MariaDB에서 제공하는 방식은 ECB 이다.)

앞의 두가지 방식은 단방향 암호화이며, AES128은 양방향 (복호화가 가능한) 암호화이다.

앞에 입력한 것이 암/복호화 대상 String 이며, 뒤에 있는것이 암/복호화에 사용되는 Key 이다. (Key는 보관을 잘 해야겠지)

-암호화

SELECT HEX(AES_ENCRYPT('ABCDE', 'ENCRYPTKEY'));

-복호화

SELECT CAST(AES_DECRYPT(UNHEX('F1A4E3DE47FAA99A3FA067F58CD67DC6'), 'ENCRYPTKEY') AS CHAR) ;

최근 살이 너무 많이 쪄서, 운동을 해야겠다고 생각을 했다.

하지만 퇴근하면 8~9시가 되고, 조금만 밍기적 거리면 잘 시간이 되어 운동할 시간이 없었다.

운동을 찾아보니 Plank 운동이라고, 하루에 몇분만 투자하면 살이 쏙 빠진다는 홈쇼핑적 글들을 많이 보았다.

내가 해야 할 운동이다 생각하고 실제로 좀 따라해봤다.

.... 생각보다 너무 힘들었다.

 포기할까 싶었는데, 조금씩 시간을 나눠서 횟수와 시간을 늘려나가면 된다는 말에 운동 방법을 그렇게 해보기로 했다.

하지만, 항상 공부하기 전에는 책상 정리를 하듯이, 나에게 맞는 앱을 검색해도 너무 많은 기능들이 있길래 그냥 내가 만들기로 했다.

가장 쉽고 빠르게 만들 수 있는 것은 당연히 웹이고, 그걸 더 빠르게 만들기 위해서 Bootstrap을 활용해서 UI를 구성했다.

우선 Plank운동의 횟수와 각각의 lab time을 체크하기로 했다.

Start 버튼과 Pause 버튼은 toggle이 되어야 하고, Reset 버튼도 추가했다.

각각의 기록들은 누적되어 쌓이고, 개별 item별로 삭제도 가능하여야 한다.

이러한 기준으로 HTML, JS, CSS 파일 3개로 구성했으며, 소스는 아래와 같다.

Bootstrap을 사용해보는 것이 목적이었기 때문에, JS는 웹에서 검색하여 여러가지 중, 적당한 것으로 사용했다.

plankRecord.html

 -주석 처리한 부분은 나중에 추가로 개발할 수도 있어서 UI만 추가했었던 부분이다.

 -사용자 로그인, 그리고 데이터 저장을 위한 부분이다. (나중에 책상정리가 더 필요하면 개발 예정)