많은 질문들을 주셔서 먼저 감사드립니다. 다른 분들도 답변을 드려야하기 때문에 대표적으로 세번째 질문에 먼저 답변 드리겠습니다. 원격 근무자, 외주 인력 및 파트너에 대한 효율적인 인증, 접근 제어, 감사 시스템 운영을 위한 우선 4가지 정도를 특히 고려하셔야 합니다. 1) 강력한 다단계 인증(MFA) 의무화, 2) 제로 트러스트 기반의 최소 권한 접근 제어, 3) 세분화된 역할 기반 접근 제어(RBAC), 4) 활동 모니터링 및 감사 강화를 통해서 위협에 대한 가시화를 확보하는 것이 중요합니다.
맨디언트가 분석한 클라우드 침해 사고의 공통 특징은 잘못된 구성(Misconfiguration), 취약한 ID/접근 관리(IAM) 및 서비스 계정 키 관리 미흡, 그리고 불충분한 로깅/모니터링입니다. 이를 기반으로 조직은 IAM 권한의 최소화 및 정기 감사, 서비스 계정 키의 안전한 관리, 그리고 통합된 로깅 및 위협 탐지 시스템 구축을 최우선으로 점검해야 합니다. 특히, 클라우드 환경 내 잘못된 설정과 과도한 권한 부여를 식별하고 수정하는 것이 가장 중요합니다.
인포스틸러는 다양한 경로를 통해 사용자 시스템에 침투하며, 주로 사용자의 부주의나 시스템의 취약점을 악용합니다. 엔트포인트만 특정하여 얘기하기 보다는 여러 부분을 함께 보안 탐지 및 모니터링을 강화하는 것이 필요합니다. 피싱(Phishing) 이메일 및 스피어 피싱(Spear Phishing), 악성 웹사이트 및 드라이브-바이 다운로드, 크랙 소프트웨어, 불법 다운로드 및 토렌트 및 취약점 익스플로잇(Exploit) 또는 USB 드라이브 등 이동식 저장 매체가 대표적인 attack vector로 고려할 수 있겠습니다.
쉽게 이해하실 수 있게 Mitre ATT&CK에 등록된 TTPS(Tactics, Techniques, and Procedures)들이 얼마나 침해사고 현장에서 확인되었는지 확인된 부분입니다.
아직 답변이 없습니다
Google Cloud는 API 보호를 위해 강력한 ID/접근 제어, 다층 네트워크 보안(WAF, DDoS, 경계 통제), 데이터 암호화, 그리고 고급 모니터링 및 자동화된 위협 탐지 기능을 통합적으로 제공하고 있습니다. 이러한 기능들을 활용하여 API 취약점 공격, 데이터 탈취, 봇 공격 등 다양한 위협에 효과적으로 대응하고, 클라우드 환경에서 API의 안전을 확보할 수 있습니다.
클라우드 침해 사고 조사 시 공격자의 Lateral Movement(측면 이동)를 허용하게 되는 가장 흔한 IAM(Identity and Access Management) 정책 설정 실수는 다음과 같습니다. 대표적으로 과도한 권한 부여, 와일드카드 권한 사용, 사용하지 않는 계정/권한 방치, 서비스 계정 키 관리 부실 등을 예로 들 수 있을것 같네요.
암호화폐 시장의 성장과 함께 스마트 계약 및 디파이(DeFi) 플랫폼을 노린 공격은 점점 더 정교해지고 있습니다. 이러한 공격들은 막대한 자산 손실과 사용자 신뢰 하락으로 이어질 수 있어, 최신 동향을 파악하고 선제적으로 대응하는 것이 매우 중요합니다. 맨디언트의 경우는 이러한 새로운 환경에 대한 진단 및 제안을 위해서 컨설팅을 사전에 진행하고 그에 따른 최적의 대응 프레임워크를 제안 드리고 있습니다.
현재 번역 작업 중이고, 7월 중순 쯤 예상하고 있습니다.
클라우드 환경에서의 보안은 기존 온프레미스와는 다른 접근 방식이 필요하지만, 중소기업도 충분히 효과적인 보안 전략을 수립하고 실행할 수 있습니다. 핵심은 클라우드 공유 책임 모델을 명확히 이해하고, CSP의 기본 보안 기능을 최대한 활용하며, 강력한 ID 및 접근 관리와 데이터 암호화를 기본으로 삼는 것입니다. 여기에 직원들의 보안 인식 교육과 필요 시 외부 전문가의 도움을 받는다면, 제한된 자원으로도 충분히 안전한 클라우드 환경을 구축하고 운영할 수 있지 않을까요? 구체적인 부분은 미팅을 통해서 추가적인 설명을 드릴 수 있도록 하겠습니다.
온프레미스와 클라우드를 병행 사용하는 하이브리드 클라우드 환경에서는 편리함과 유연성이라는 장점만큼이나 복잡성과 보안 위험이 증가할 수 있습니다. 따라서 통합적인 관점에서 신중한 계획과 지속적인 관리가 필수적입니다. 고려할 사항들이 참 많은데 네트워크 및 연결성, 데이터 관리 및 보안, 신원 및 접근 관리, 가시성 및 모니터링 그리고 규제 준수 및 거버넌스 에 대한 부분을 전체적으로 검토하셔야 합니다.
사고 대응 지표를 작성할 때는 사고가 발생했을 때 얼마나 빠르고 효과적으로 대응하고 복구했는지를 측정하는 것이 중요합니다. 핵심 목표는 복구 시간을 단축하고, 비즈니스 연속성을 확보하며, 재발을 방지하는 것이 중요합니다. 그래서 침해사고에도 골든 타임을 중요하게 얘기합니다.
아직 답변이 없습니다
아직 답변이 없습니다
관련된 정보는 영업문의를 통해 요청주시길 바랍니다. 감사합니다. 아이티센클로잇 이준희 팀장 / [email protected]
네, 맞습니다. 자체 서빙은 일반적으로 클라우드 제공업체나 연구 기관 등이 미리 학습시켜 놓은(pre-trained) 대규모 언어 모델을 기반으로 합니다. 여기에 기업은 자신들의 특정 도메인 데이터나 목적에 맞춰 추가적인 파인 튜닝(fine-tuning) 과정을 거쳐 모델을 최적화합니다. 이후 이 파인 튜닝된 모델을 자체 인프라에 직접 배포하고 운영하여 서비스를 제공하는 방식입니다.
아직 답변이 없습니다
API 서비스와 자체 개발을 하이브리드로 운영하는 시나리오에서는 민감 데이터 처리나 핵심 비즈니스 로직은 자체 개발 LLM으로, 일반적인 질의응답이나 보조적인 기능은 API 서비스로 분리하여 대응하는 것이 효과적입니다. 이를 통해 데이터 주권 및 보안을 확보하면서도 개발 속도를 높이고 운영 비용을 최적화할 수 있습니다. API 게이트웨이를 통해 요청을 적절한 LLM으로 라우팅하하는 방법으로 설계하는 것도 고려해볼 만합니다.
LLM 파인튜닝 모델을 On-demand로 서빙할 때 CI/CD 전략은 모델 학습 파이프라인과 서빙 파이프라인을 분리하여 구성하는 것이 효율적입니다. 모델이 파인튜닝되면 자동으로 모델 레지스트리에 등록되고, 새로운 모델 버전이 준비되면 CI/CD 파이프라인을 통해 서빙 환경에 배포됩니다. 이때 카나리 배포나 롤링 업데이트 방식을 사용하여 서비스 중단 없이 모델을 업데이트하고, 문제가 발생하면 빠르게 롤백할 수 있도록 설계해야 합니다.
특정 "규모"를 정확한 숫자로 제시하기는 어렵지만, API 서비스 비용이 내부 인프라 구축 및 운영 인력 비용을 포함한 총소유비용(TCO)을 초과하고, 동시에 데이터 주권 및 비즈니스 핵심 자산으로서의 LLM 통제권 확보가 중요해지는 시점이 자체 서빙으로의 전환을 진지하게 고려해야 하는 시점이라고 할 수 있습니다.