EMD Blog

[GCP] Cloud Armor - 보안 정책과 규칙(1)안녕하세요. Emadam입니다.이번 포스팅에서는 GCP Console 및 gcloud를 사용해 Cloud Armor를 구성해보면서 직접 외부 공격을 방어해보는 과정을 다뤄보겠습니다.사전 설정Cloud Armor를 테스트하기 위해 전역 외부 어플리케이션 부하 분산기를 구성해보겠습니다. 구성할 리소스는 다음과 같습니다.웹서버가 설치된 VM Instance전역 외부 어플리케이션 부하 분산기위 리소스 생성 시 비용이 발생합니다. 주의해주세요.사전 설정은 gcloud를 사용해 진행합니다. 혹시 gcloud가 설치되어 있지 않다면 아래 문서를 참고해서 설치해주세요.gcloud CLI 설치 가이드gcloud CLI가 설치되었다면 계정 설정 및 Project 설..

안녕하세요. Emadam입니다. 이번 포스팅에서는 Cloud Armor를 도입하면서 검토하고 공부했던 내용을 공유하려 합니다. 최근에 신규로 오픈한 시스템이 공격을 받았던 일이 있었습니다. 공격자는 시스템 내 PHP 파일을 스캐닝하고 SQL 인젝션 공격, 원격 코드 실행 등을 시도했습니다. 다행히 시스템에 시큐어 코딩이 적용되어 있어 큰 피해는 입지 않았지만, 공격 빈도가 잦고 공격 방식의 예측 불가능성을 고려하여 보안 강화가 시급하다는 판단에 도달했고 Cloud Armor를 도입하기로 결정하였습니다.Cloud Armor란? Cloud Armor는 DDoS 공격, 크로스 사이트 스크립팅(XSS), SQL Injection과 같은 여러 공격으로부터 어플리케이션을 보호하는 GCP의 보안 서비스입니다. L3 ..

안녕하세요. Emadam입니다. 얼마 전 회사에서 저희 팀에서 랜섬웨어가 걸리는 사태가 발생했습니다.랜섬웨어에 걸린 PC는 구글 드라이브를 네트워크로 연결해서 사용하고 있었기 때문에 해당 PC에 연결되어 있던 모든 공유 드라이브의 접근 가능한 파일들은 전부 암호화되어 버렸습니다. 이렇게 랜섬웨어로 인해 구글 드라이브의 파일이 암호화되는 경우 크게 두 가지 방식으로 암호화가 될 수 있습니다.모든 파일을 삭제 후 암호화된 파일을 삽입파일을 삭제하지 않고 암호화위에서 어떤 방식으로 암호화가 되었든 복구는 가능합니다. 전자의 경우 삭제된 파일이 휴지통에 있기 때문에 휴지통에서 복구하면 되고 후자는 파일 버전을 이전 버전으로 되돌리면 됩니다.또한 구글 드라이브는 검색이 편리하게 되어 있기 때문에 파일 수가 그렇..

개요 온프레미스와 클라우드 간의 전용선을 구축하는 것은 상당히 많은 시간이 소요된다. 신규 증설 같은 경우는 최소 2주 이상은 소요되는 경우가 많은데, 이 때문에 시간을 넉넉하게 잡고 전용선 증설을 하는 것이 좋다. 하지만 전용선 증설에는 각 부서간의 합의와 업체간의 계약이 이루어져야 하기 때문에 시간을 맞추지 못해 곤란해지는 상황이 종종 발생하기도 한다. 만약 시간을 제대로 맞추지 못해 전용선 증설 일정이 틀어질 것 같다면 어떻게 해야할까? VPN 같은 것을 사용할 수도 있고 사내 정책에 따라 임시로 공인 IP를 매핑해 작업을 이어나갈 수 있을 것이다. 하지만 이런 상황도 힘들다고 하면 다른 전용선을 빌려쓰는 방법도 고려해볼 수 있다. 전용선을 빌려쓰는 방법은 두 가지를 고려할 수 있다. 1. 신규 V..

IDC GCP Shared VPC ←—- (VPC Peering) —→ Other VPC 위처럼 구성했을 때 Other VPC에 대한 네트워크 대역들이 온프레미스에 전파가 안되고 있음. 문서상에서는 동적으로 경로를 전파(BGP로)한다고 적혀있기는 한데 전파가 안됨. 일단 VPC 에서 route 정보에 해당 네트워크 대역(Other VPC)이 등록은 되어 있음. 내용 확인해 보겠음. ========= 해결 됨 요약하면 다음과 같음. IDC Project A VPC Project B VPC 이렇게 구성하려할 때 IDC와 Project B VPC간 라우팅 정보는 수동으로 전파해야함. Peering 생성할 때 Project A > Project B로 커스텀 경로 내보내기..

현재 상황은 아래와 같음. ============================================================ - 현재 구축되어 있는 GCP의 네트워크(shared VPC 사용 중)와 IDC 센터는 인터커넥트로 연결되어 있음. - GCP 내에는 Cloud SQL이 비공개 IP로 구성되어 있으며, IDC에서 이 Cloud SQL로 접근해야하는 상황. - 하지만 IDC의 IP 대역은 172.17.0.0/16이기 때문에 GCP 비공개 서비스에 직접적으로 접근 불가.(GCP의 172.17.0.0/16 대역은 Docker 브리지로 예약) - 때문에 Proxy VM을 구축해서 IDC -> Proxy VM -> Cloud SQL 형태를 만드려고 함. - 여기서 Proxy VM은 MIG+자동복..

gcloud compute instance-groups managed rolling-action stop-proactive-update study-managed-instance-group \\ --zone=asia-northeast3-a gcloud compute instance-groups managed rolling-action stop-proactive-update 명령어가 MIG내 최대 인수턴스 개수에 어떤 영향을 미치는 지 궁금함. 그래서 GCP 케이스에 아래와 같은 내용으로 등록하였음. ==============[케이스 질문]================ 스테이트풀 구성 중 궁금한 점이 있어 문의드립니다. 처음에 아래와 같이 스테이트리스 인스턴스 그룹과 오토스케일링을 설정했습니다. ======..

Cloud 모니터링의 알림 채널을 Pub/Sub으로 설정해 알림 메세지를 게시하면 Cloud Functions에서 메세지 내용 확인 시 데이터가 암호화되어 있는 것을 볼 수 있다. 모니터링 알림 스키마 구조 https://cloud.google.com/monitoring/support/notification-options#pubsub 위 문서에서 중간쯤 보면 스키마 구조와 설명이 적혀있다. 하지만 메세지를 출력해보면 아래와 같이 나온다. (검은색으로 칠해진 부분은 base64 데이터이다.) 즉, 아래구조로 출력된다. ( Message ID와 Publish Time은 Pub/Sub에서 생성) { data : string, messageId: string, message_id : string, publish..

Cloud Function을 HTTP 트리거로 생성함. 구독의 서비스 계정에는 해당 함수에 대한 호출자 역할을 부여하였으며 인증을 위해 서비스 계정 토큰 생성자 역할을 부여하였음. Cloud Function은 외부 호출을 허용 해놓은 상태. Publish하면 구독이 메세지를 받아오긴 하나 Push가 되지 않음. Cloud Logging으로 쿼리해보았지만 나오는 로그도 없음. 일단 문서 추가로 확인해보고 케이스에 등록할 예정. 도저히 모르겠음. 해당 내용 케이스로 등록함. ================== 케이스 등록 내용 ================= Cloud Function을 HTTP 트리거로 배포해 Pub/Sub으로 호출하려 합니다. 현재 아래처럼 구성하였습니다. Cloud Function - H..

GCP Cloud Function을 Pub/Sub 트리거를 통해 구성할 시 자동으로 구독이 생성되고 gcf-{cloud function name}-{region}-{topic} ID를 갖게 됨. 이는 기존 조직의 네이밍 룰을 따르고 있지 않아 관리가 불편해짐. Pub/Sub 트리거 구성 시 구독 ID를 직접 지정할 수 있는지 확인해 보았으나 관련 문서를 찾지 못했음. 그래서 GCP에 케이스를 남겨 아래와 같은 답변을 받음, ========================= 해당 이슈에 대하여 재현 해본결과 subscription 은 cloud functions 에 의해 자동으로 생성되며 안타깝게도 이 구독은 Cloud Functions에서 관리하므로 변경이 불가한것으로 확인 되었습니다. 말씀 하신대로 구독 ..