정보보안 (12) 썸네일형 리스트형 대퇴사 시대 퇴사자 관리는 어떻게 해야 하는 가-M365 백업/복구 우리는 Saas 서비스를 사용하게 될 경우 사실 모든 것이 서비스로 제공된다고 착각했으며 백업 역시 기능에 포함되어 있다고 생각했습니다. 하지만 여기 MS의 약관을 살펴보면 백업에 대한 기능은 없기에 3자 솔루션으로 백업하라는 문구를 떡 하니 찾아볼 수가 있는데요. 사실 M365의 경우 E3, E5 이상의 tier를 사용 할 경우 E-discovery 기능과 아카이브 사서함 등을 통해 백업의 기능을 하긴 하지만 유저 친화적이지 않는 사용법과 비싼 라이선스를 구매해야 한다는 아쉬움이 있습니다. MS의 M365 뿐 아니라 다른 Saas 솔루션 역시 마찬가지로 고객의 데이터에 대해서는 책임을 지지 않습니다. 이 그림을 보게 되면 모든 형태의 서비스들에 대해 데이터는 결국 고객, 사용자가 책임져야 한다는 것을 .. 백업 데이터를 믿지 마라! 백업 데이터에 대한 제로 트러스트 2017년 SMB의 취약성을 이용한 Wannacry 랜섬웨어로 인해 전 세계가 난리가 난 적 있습니다. 그 후 우리는 랜섬웨어를 대응하기 위해 백업이라는 전략을 택했습니다. 즉 백업 데이터를 가지고 있기 때문에 랜섬웨어에 걸려도 괜찮다? 또는 백업 데이터로 복구하면 된다 라는 전략을 가지고 갔지만 이는 백업 데이터가 온전히 잘 관리되고 있을 때만 가능했었습니다. 사실 우리는 열심히 꾸준히 백업을 정해진 스케줄에 맞게 수행하지만 복구해 본 경험? 은 사실 거의 없거나 또는 한번 도 없을지도 모릅니다. 일단 백업 데이터만 가지고 있으면 랜섬웨어를 대응할 수 있다고 알고는 있었지 실제로 랜섬웨어에 걸려서 가지고 있던 백업 데이터를 사용해 복구해 보거나 모의 훈련을 통해 복구에 필요한 경험과 프로세스를 가지고 .. 제로 트러스트 아키텍처 SAML 2.0 SSO 연동으로 DevOps 툴 접근제어JenKins (역할, role 기반으로 권한을 분할하자) 이번에는 젠킨스를 AD 계정으로 로그인하면서 역할 admin, user, 서비스 A, 서비스 B에 맞는 권한을 부여해 보겠습니다. 단순 SAML 2.0 연동을 하게 되면 오로지 접근 제어밖에 할 수 없게 됩니다. 접근 권한 = admin 이 되어 모든 사용자가 admin이 되게 됩니다. 하지만 admin과 user 간 권한이 분리되어야 하며 admin 은 지정된 운영자만이 권한을 가질 수 있습니다. 그리고 user는 모든 Item에 접근 가능해서는 안되고 오직 권한이 부여된 Item에 대해서만 권한을 가져야 합니다. 위와 같이 AD의 admin 그룹에 속하는 유저만이 젠킨스의 admin 권한을, user 그룹과 A 서비스 그룹에 속해야만 젠킨스의 A 서비스에 대해 권한을 가져야 합니다. AD 와 젠킨스 .. 제로 트러스트 아키텍처 SAML 2.0 SSO 연동으로 DevOps 툴 접근제어JenKins Gitlab, Github, Jenkins 등 DevOps, CI/CD을 위한 툴이 많습니다. 하지만 대부분의 툴들은 계정들을 자체적으로 생성해 쓰게 되는데 이른바 "admin" 같은 계정을 만들어 사용자들은 패스워드를 공유하며 하나의 계정을 돌려 쓰게 됩니다. 이러다 보니 누가 언제 admin 이란 계정으로 들어가 어떤 작업을 했는지 추적이 불가능하며 아무렇게 방치되는 패스워드는 해킹의 노출에 심각하게 방치되어 있습니다. 그렇다면 일일히 사용자마다 개별 계정을 만들어 주면 되지 않을까라고 생각할 수 있지만 사용자가 가지고 있는 devops 툴 계정이 몇 개나 늘어날지 그리고 계정들이 똑같은 아이디/패스워드로 관리된다면? 퇴사하거나 부서 이동한 사용자의 계정을 제거하지 못하고 방치된다면? 늘 염두해둬야 .. 제로 트러스트 아키텍처 컨테이너, 쿠버네티스 보안은 어떻게? On-premise 서버나 클라우드의 VM의 경우 Vault 라 불리는 제로 트러스트 아키텍처 솔루션에 의해 접근제어 권한 제어가 가능합니다. 하지만 도커의 컨테이너 또는 쿠버네티스 환경에서는 어떻게 접근제어를 적용할 수 있을까 라는 물음에서 시도했던 정책 한 가지 소개하려 합니다. 사실 컨테이너의 경우 IaC 로서 장애가 났거나 다른 문제점이 있을 경우 기존의 것을 내리고 새로운 컨테이너를 run 시키기 때문에 컨테이너에 어떻게 접근하고 어떻게 접근을 제어하지를 고려할 필요가 없습니다. 하지만 일부 희박하게 컨테이너 내부에 들어가서 필요한 작업이 있을수도 있다라는 생각에 컨테이너 접근제어 방안에 대해 생각하게 되었습니다. 사실 위의 아키텍처처럼 Baston(kubectl) 또는 도커의 호스트 OS 에서.. 제로 트러스트 아키텍처 On-premise 리눅스 서버 2 이전에 제로 트러스트 아키텍처 On-premise 리눅스를 대상으로 하나의 무난한 정책을 소개한 적 있습니다. 그런데 실제로는 수많은 서버, 수많은 사용자를 운영하기 위해서는 다영한 솔루션과의 연계가 필요합니다. 이 글에서는 다른 솔루션과 연계한 운영측면에서의 내용을 다루겠습니다. 우선 사용자 관리 측면에서 보겠습니다. AD의 운영자 또는 인사관리직원이 적절하게 인력을 외주, 개발, 운영 그룹에 직접 포함시킬 수도 있지만 enterprise 급 회사라고 가정한다면 일일히 관리한다는 것은 쉽지 않은 일입니다. 게다가 신규입사, 퇴사등, 일시적인 프로젝트 인력에 대한 관리등 해야 할 일들이 너무 많습니다. 각 계정들의 관리 및 변경 내역을 기록으로 남기기 위해서 IAM 솔루션과의 연계가 필요합니다. 이를 통.. 제로 트러스트 아키텍처 On-premise 리눅스 서버 1 아무것도 믿지 말라라는 컨셉에서 시작한 ZTA(Zero Trust Archictecture) 라는게 모든 권한을 빼고 JIT(Just In Time) 필요할때만 주자 그리고 모든것을 감시하자라는 의미입니다. 그럼 On-premise 리눅스 서버를 대상으로 제로 트러스트 아키텍처 정책을 하나 소개하고자 합니다. 아키텍처에 대해 설명하자면 대상 서버들은 Vault 라는 접근제어,권한제어 솔루션을 통해서만 접근이 가능합니다. 모든 리눅스 서버의 inbound ssh port 는 Vault 가 됩니다. 이를 통해 대상 서버로 접근가능한 경로는 오직 하나뿐이게 됩니다. Vault에 로그인하기 위해서 AD 을 연동하게 됩니다. AD의 인사정보를 연동한 후 크게 3개의 그룹(외주,개발,운영) 내 속한 계정은 Vaul.. OSI 7계층 네트워크를 공부하면서 가장 기본적인 내용이자 늘 헷갈리는 그것 OSI 7 계층에 대해 좀 더 쉽게 알아보도록 하겠습니다. 위키피디아를 보게 되면 설명이 나와있지만 정말 이해가 안 되는 설명이 아닐까라 생각합니다. 위키피디아에 나오는 설명을 바탕으로 조금 더 쉽게 이해하고자 합니다. 이메일을 송신하고 수신하는 과정을 예를 들어 설명해 보겠습니다. 송신자 A는 크롬을 켜 구글의 본인 계정으로 접속해 수신자 B에게 몇백자의 메시지가 포함된 약 500byte 크기의 메일을 전송했습니다. 이 데이터는 7 계층 이서 1 계층으로 각 단계를 거쳐 수신자에게 전송되며 다시 1 계층에서 7 계층의 단계를 거쳐 최종적으로 수신자는 이메일을 확인할 수 있게 됩니다. 이 과정을 위키피디아의 내용을 토대로 살펴 보겠습니다. 계.. 이전 1 2 다음
