Keyword
- K8S
- Cloud
- Ducktail
- SBOM
—
Contents
| List | Contents |
|---|---|
| 1 Default configurations | K8S는 유연성과 민첩성을 극대화되도록 설계됨 보안을 위해 적절한 구성 필요 |
| 2 Multiple admins | 여러 엔지니어가 일상적인 작업을 하면서 높은 권한 (CLUSTER_ADMIN)을 쓰도록 허용하는 것은 문제 |
| 3 No access restrictions | 많은 관리자가 개발자의 dev/stage/prod 클러스터 엑세스 유형 제한을 설정하지 않음, 즉 모든 개발자가 모든 다른 환경의 전체 엑세스 권한이 필요한것이 아님 대부분 개발자가 가져야 하는 유일한 권한은 로그 |
| 4 Assuming isolation | 클러스터가 클라우드 VPC와 격리돼 있다는 가정으로 보안의 필요성을 간과 |
| 5 Failure to secure imported YAMLs | 퍼블릭 YAML을 가져오면 효율적이지만 잘못된 환경 구성 문제 발생 가능성이 존재 |
| 6 Storing secrets in ConfigMaps | 편의를 위해 민감한 정보를 configmaps에 저장하는 개발자들이 많음 |
| 7 No regular scans | SDLC 및 CI/CD 파이프라인에서 정기 검사가 필요 K8S 환경 내 문제를 감지할 수 있는 도구나 계획이 없는 회사가 많음 |
2.블로그 | 모두가 ‘클라우드’ 외칠 때 ‘로컬 서버’ 선택해야 하는 이유
클라우드 OPEX(operational expenses)가 인하우스 CAPEX(capital expenses) 대비 뛰어나다고 단정지을 수 없음.
만약 기업이 고정적이고 예측할 수 있는 워크플로우를 갖고 있다면 완전히 다른 이야기
1. 기술지원: 로컬 하드웨어를 활용하는 것과 비교 할 수 없음.
(인프라 통제 관련 이유)
2. 인하우스 앱보호: 온프레미스로 운영하는 레거시 어플리케이션은 로컬서버를 이용하는 것이 더 효율적
3. 대역폭: 내부 LAN의 빠른 속도를 클라우드에서 구현하려면 비용이 저렴하지 않음.
4. 프라이버시: 데이터 프라이버시에 엄격하다 해도 온프레미스에 저장하는 것 만큼 안전성을 유지할지 의문.
5. 오버 프로비전: 클라우드 과금제 (플렉세라(Flexera)의 2021 클라우드 현황(2021 State of the Cloud) 보고서)
클라우드 비용의 30%정도가 낭비
일반적으로 기업은 필요한 성능보다 더 넉넉하게 구매
하지만 클라우드에서는 현재 워크로드에 필요한 만큼만 구매할 수 있으며 그 이상이 필요하면 오토 스케일링, 리소스 스케일링 등 다른 방법을 배워야 하지만 이를 완벽하게 익히기가 쉽지 않음.
Notation
오버 프로비저닝: SSD저장 공간의 특정 부분을 캐시로 컨트롤러에 할당하는 최적화된 펌웨어 기술
프로비저닝: 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 준비해두는 것
스토리지 프로비저닝 종류
fat provisioning(thick provisioning): 전통적인 스토리지 프로비저닝 방식으로 단순히 사용할 공간을
물리적 스토리지로 할당. 
thin provisioning: 사용하는 만큼 공간이 할당되는 온디맨드 방식
씬 프로비저닝은 씩 프로비저닝처럼 물리적 용량에 할당 공간이 한정되지 않음. 가상화 기술을 통해 물리적 스토리지 공간 이상으로 공간을 할당할 수 있고 데이터 쓰기 요청이 발생한 후에야 물리적 디스크와 엮임
(단점으로 지속해서 모니터링을 하지 않으면 어느 순간 가용 공간이 바닥날 수 있음) 
3.‘페이스북 비즈니스 계정만 노린다’… 새 공격 수법 ‘덕테일’ 발견
덕테일로 명명된 맬웨어를 통해 비즈니스 계정 이용자를 겨냥
특히 Infostealer 전용 멀웨어 컴포넌트를 개발하여 특정 소수의 사용자만을 공격하기에 위험
공격대상이 악성 링크를 열게 되면 맬웨어가 설치되어 브라우저 캐시 정보 및 수 많은 개인 데이터(2FA 코드, IP주소, GPS 정보, 신용카드 정보 등)를 추출
4.“선택 아닌 필수” SBOM을 작성하는 베스트 프랙티스와 추천 프로그램 8선
오픈소스 구성요소를 포함한 애플리케이션은 92%이며 현대 프로그램은 평균 70%가 오픈소스 소프트웨어로 구성됨.
리눅스 재단과 OpenSSF에 따르면 SBOM에 정의는 다음과 같음.
“소프트웨어 패키지와 그 내용을 고유하게 식별할 수 있는 기계가 읽을 수 있는 메타데이터이며, 저작권 및 라이센스 데이터를 포함한 기타 정보가 포함 가능하다. 또한 조직간의 공유되도록 설계되어 소프트웨어 공급망 참여자가 제공하는 구성요소의 투명성을 제공하는데 유용”
SBOM에는 다음과 같은 사항이 포함됨
1.애플리케이션의 오픈소스 라이브러리
2.프로그램 플러그인, 확장 프로그램 및 추가 기능
3.개발자가 사내에서 작성한 사용자 지정 소스코드
4.이전 버전, 라이센스 상태, 패치에 관한 정보
5.자동 구성요소 암호화 서명 및 확인
6.CI/CD 파이프라인의 일부로 SBOM을 생성하는 자동 검색 기능
특히 CI/CD 파이프라인의 일부로 만들려는 노력이 있으며 SBOM으로 추적할 수 메타데이터가 매우 방대함을 고려해야함.
가트너는 다음 기능을 갖춘 도구를 추천했으나 아직까지는 해당 기능을 모두 제공하는 프로그램은 존재하지 않는 상황
1.빌드 프로세스 중 SBOM 생성
2.소스코드 및 바이너리(ex.컨테이너 이미지) 분석 3.아티팩트에 대한 SBOM 생성
4.SBOM 편집
5.SBOM을 사람이 읽을 수 있는 형식으로 보고, 비교하고, 가져오는 유효성 검사
6.SBOM내용을 한 형식/파일에서 다른 형식/파일로 병합하고 변환
7.API 및 라이브러리릍 통해 다른 도구에서 SBOM 조작 지원
대표적인 SBOM의 사용례는 다음 3가지로 나뉨
1.소프트웨어 생산자: SBOM을 사용하여 소프트웨어 구축 및 유지 보수 지원
2.소프트웨어 조달자: SBOM을 사용해 사전 구매 보증을 알리고, 할인 협상 및 구현 전략 계획
3.소프트웨어 운영자: SBOM을 사용하여 취약성 자산을 파악하고 공급망 위험을 신속하게 식별
가트너는 2025년 까지 기업의 60%가 SBOM 의무화를 할 것으로 예상하나 현재는 아직 20%미만
Notation SBOM의 표준은 아직 정해지지 않았으나 대표적인 3가지
1.SPDX(ISO/IEC-5962:2021 규격 게시): SPDX는 태그/값(.spdx),JSON(.spdx.json),YAML(.spdx.yml),RDF/xml(spdx.rdf),스프레드시트(.xls) 다섯가지 파일 형식 중 하나를 사용하며 여러 파일 형식의 소프트웨어 구성요소를 전달하기 위한 표준 언어 제공
2.SWID(ISO/IEC-19770-2:2015 소프트웨어 식별 태그): 소프트웨어 제품을 설명하기 위해 구조화된 메타데이터 형식을 정의.
3.CycloneDX(OWASP): SPDX 규격을 준수하는 경량 SBOM.