가끔 보자, 하늘.

plain text 형태로 S3에 업로드한 자료들이 맘에 걸려서 bucket에 올린 자료들을 모두 암호화 하기로 결정했습니다. 여러 복잡한 절차들이 있을 줄 알았는데 생각보다 큰 불편함없이 마무리 할 수 있어서 좋긴 한데, 뭔가 하다 만 느낌이라 걱정이 싹 가시진 않네요. 기존에 자료를 업로드 하는 app과 자료를 읽는 app 모두에서 별다른 조치를 할 필요는 없었습니다. IAM에 설정된 사용자에 정책을 추가하는 것과 Bucket에 암호화 설정하기. 그리고 기존 데이터 암호화하기로 모든 작업이 끝나네요. 이 설정이 편한게 데이터 암호화를 클라이언트가 직접 하는게 아닌 server side encryption이라 별로 손 댈게 없어서 좋았습니다. put, get 시 별도 하는게 없어 암호화 되었는지 아닌지..

마지막으로 직접 인증서를 발급하고 이를 개인용 사이트에 적용하는 방법을 상세히 알아보겠습니다. 이 테스트는 CentOS 7.x , OpenSSL, Nginx에서 실행되었습니다. 인증서 발급을 위한 준비 인증서를 발급한 기록을 위해 두 가지 파일이 필요합니다. 하나는 발급된 인증서의 정보를 기록하는 것과 serial을 기록하는 파일, 이렇게 두 개의 파일을 준비해야 합니다. touch /etc/pki/CA/index.txt echo '00' > /etc/pki/CA/serial 추후 인증서를 발급 후 두 파일을 보면 아래와 같습니다. V 210109061528Z 00 unknown /C=KR/ST=Seoul/O=COMPANY/OU=DEV1/CN=your_domain/emailAddress=your_emai..

이번에는 우리가 알고 있는 공인인증서는 무슨 역할을 하고, 왜 인증된 기관에서 받아야 하는지 알아보겠습니다. 인증서(Certificate)는 무엇이며 왜 만들어졌는가? 인증서는 아래와 같은 내용이 포함되어 있습니다. - 발행 장소 - 소유자 이름과 email 주소 - 인증서의 용도, 유효기간 - Common Name(CN) - Public Key - Hash 인증서에 포함된 Public Key는 발행 주체(예를들면 서비스를 제공하는 웹 사이트 등)의 PK이며, 이 정보들은 인증기관의 private key로 암호화 되었습니다. 브라우저들은 유명한 인증 기관의 Public Key를 이미 포함하고 있어 인증서를 받아 발행 주체의 Public Key를 확인할 수 있습니다. 인증서를 공인된 인증 기관에 신청하는 ..

회사 자체에서 사용되는 웹 사이트에 SSL을 도입할 일이 생겼는데, SSL 도입 자체가 처음이라 도입 과정의 내용을 정리해 보았습니다. Self Signed Certificate이라고 하는 용어도 이번에 첨 알게 되었네요. 필요한 사전 내용부터 도입 과정, 예외상항에 대해서 순서대로 정리 보았으니 참고 되시길 바랍니다. (* 처음 해보는 거라 잘못된 정보, 오류가 있을 수 있습니다. ^^;;) 알고 가야 할 것들! SSL(Secure Socket Layer)이 무엇인지는 너무 많은 글들이 있으니 여기서는 SSL 도입에 필요한 요점만 정리하겠습니다. 사실 TLS(Transport Layer Security)지만 SSL이라고 부르기 때문에 그대로 사용하겠습니다. HTTP와 HTTPS의 차이 HTTP는 평문(..

비지니스 로직에서 logstash로 tcp를 바로 데이터를 전송한다면 아래와 같은 흐름으로 설계가 될 것입니다. 이 경우 logstash 혹은 elasticsearch에 문제가 있을 경우 바로 데이터 손실이 발생할 수 있습니다. logstash와 elasticsearch의 문제 발생 혹은 점검 중 데이터 손실이 발생하지 않도록 전송할 데이터를 일시적으로 혹은 일정 기간 동안 보관했다가 logstash와 elasticsearch가 정상화 되었을 때 다시 전달할 수 있도록 아래와 같이 만들어 보겠습니다. 임시 저장소로는 Redis를 사용하고, 데이터 전송 흐름을 제어하기 위해 nodejs로 간단한 agent를 만들어 사용해 보겠습니다. 전달받은 로그는 모두 JSON 포멧의 텍스트로 가정합니다. const h..

Collo를 좀 더 알기쉽게 전달하기 위해 개요 및 샘플들을 제작하여 SlideShare에 공유 중입니다. 이 글에서도 링크를 추가하여 계속 업데이트 하도록 하겠습니다. https://www.slideshare.net/winninghabit/collo-01-kr Collo -01 , kr Collo를 소개합니다! https://github.com/blackwitch/Collo www.slideshare.net https://www.slideshare.net/winninghabit/collo-02-kr 불러오는 중입니다...

한동안 회사에서 진행한 Data Warehouse(이하 DW) 및 통계시스템 구축이 최근 완료되었습니다. 그리고 데이타를 저장한 Database(이하 DB) 종류, 저장된 로그의 파일 포멧 그리고 서버 위치도 다른 데이터들을 한 곳으로 손쉽게 모으기 위해 만들었던 천 줄 내외의 Javascript 코드를 정리해서 Collo라는 이름으로 github에 며칠 전 공개하게 되었습니다. Collo의 주 목표는 실시간으로 누적되는 데이터를 해당 시스템의 부하없이 DW로 가져오는 것이었으며, 마이그레이션에 대한 모든 기능을 포함한 솔루션이 아닌 손쉽게 수정, 조작 가능한 작은 유틸리티 제작을 목표로 한 프로젝트였습니다. 그리고 데이타를 가져오는 성능 보다는 안정성에 더 중점을 두어 제작하였습니다. 그리고 유지보수를..

(* 이 글은 NodeJS 10.15.1 을 기준으로 작성되었습니다. ) 한국은 GMT +9 를 기준으로 시간을 사용하며, 데이터를 다룰때도 일반적으로는 GMT +9 기준을 사용합니다. 단일 솔루션만 다룰 때는 거의 신경쓰지 않겠지만, 이기종 혹은 여러 솔루션을 한번에 컨트롤 할 때는 상당히 거슬리는 문제가 됩니다. 특히 월드 와이드 서비스를 하고 있다면요. 대부분의 DB에서 UTC 기준으로 값을 저장하기 때문에 큰 문제는 없지만, 간혹 일부 npm에서 datetime 자료형을 다룰 때 미묘한 차이가 있습니다. node-mysql(구분을 위해 임시로 node-를 붙였습니다)의 경우, 저장된 datetime 값을 그대로 가져오기 때문에 전혀 문제가 없는데 반해, node-mssql은 useUTC옵션을 제대..