긍정적 사고, 음식의 절제, 규칙적인 운동

https://www.samsungsds.com/kr/insights/1258148_4627.html

데브옵스(DevOps)와 데브섹옵스(DevSecOps)

이제는 대부분의 IT 개발자와 시스템 운영자들이 데브옵스를 잘 이해하고 있으며 많은 조직이 데브옵스 방식의 민첩성과 유연성을 바탕으로 라이프 사이클을 운영하고 있습니다. 데브옵스는 개발 주기를 단축하고 산출물을 재빨리 배포하는데 큰 장점이 있습니다. 하지만 보안 측면에서는 약점이 있는데 바로 처음부터 보안 요구사항을 적용하지 않은 상태에서 보안 이슈가 생길 경우 전체 라이프 사이클에 부정적인 영향을 미치게 된다는 점입니다. 이로 인해 데브섹옵스 모델이 나왔습니다. 데브섹옵스는 빠른 개발이라는 데브옵스의 장점에 보안을 추가해 라이프 사이클 전체에 적용하는 방법론입니다.

쿠버네티스 보안의 중요성

데브섹옵스는 보안 안정성을 기반으로 빠른 개발·배포·테스트를 지원하기 위해 컨테이너가 중심이 됩니다. 산출물을 개발하고 배포하는 사이클 중간에 보안 요소가 들어가야 하지만 무엇보다 컨테이너 자체의 보안을 우선적으로 고려해야 합니다. 전 세계에서 가장 많이 사용되면서 컨테이너 오케스트레이션을 위한 사실상의 표준이라고 할 수 있는 오픈소스 SW 플랫폼, 쿠버네티스의 보안에 신경을 써야 하는 이유입니다.

최근 미국 사이버보안인프라보안국(CISA)과 국가안전국(NSA)에서 쿠버네티스 보안에 대한 중요성을 강조하며 쿠버네티스 강화 가이드(Kubernetes Hardening Guidance)를 발표했습니다. 권고 조치는 다음과 같습니다.

1. 취약점이 있거나 구성이 잘못된 컨테이너 및 파드를 스캔해야 합니다.
2. 최소한의 권한으로 컨테이너와 파드를 실행해야 합니다.
3. 네트워크 분리를 사용하여 피해받지 않도록 제어가 가능해야 합니다.
4. 방화벽을 사용하여 불필요한 네트워크 연결을 제어해야 합니다.
5. 강력한 인증 및 권한 부여를 사용하여 사용자 및 관리자 액세스를 제한해야 합니다.
6. 관리자가 모든 활동을 모니터링하며 잠재적/악의적 활동에 대응할 수 있도록 로그 감사를 사용해야 합니다.
7. 정기적으로 모든 쿠버네티스 설정을 검토하고 취약성 스캔 및 보안 패치가 적용되어 있는지 확인해야 합니다.

위 권고 조치의 대표적인 사항은 컨테이너 이미지의 안정성, 인증과 권한 및 보안 감사 등입니다. 본 아티클에서는 쿠버네티스를 운영하거나 컨테이너 형태의 애플리케이션을 개발하는 엔지니어와 개발자 관점에서 코드 수준에서 컨테이너를 안전하게 유지할 수 있는 방법을 살펴보겠습니다.

쿠버네티스 컨테이너 보안 가이드

(1) 컨테이너 이미지 관리

컨테이너 이미지 관리는 매우 중요합니다. 이미지로 인한 취약점, 구성 결함 및 악성 코드 삽입 등으로 보안 이슈가 발생할 수 있기 때문입니다. 이미지는 애플리케이션을 실행하는데 필요한 모든 구성 요소가 포함된 정적 파일입니다. 보안 업데이트가 누락됐거나 지원되지 않는 구성 요소가 있을 경우 취약점이 발생할 수 있습니다. 만약 취약점이 존재하는 상태로 배포될 경우 보안 위험은 커지게 됩니다.

이미지 취약점이 없더라도 구성이 올바르지 않으면 공격에 노출될 수 있습니다. 불필요한 계정을 갖고 있거나 쓸데없이 네트워크에 노출되는 서비스가 있는 경우에 구성 결함이 발생할 가능성이 있습니다. 또한 컨테이너에 주입된 애플리케이션에 악성코드가 포함되는 경우도 위험합니다. 배포 환경 내 다른 컨테이너나 호스트를 공격할 수 있기 때문입니다. 이를 방지하기 위해서는 사용하는 이미지가 보안이 검증된 것인지 확인해야 하며 OS 패치가 지속적으로 적용되어야 합니다. 또한 컨테이너 이미지 자체에 스캔(Scan)을 하도록 앵커(Anchore)나 클레어(Clair)와 같은 오픈소스 SW를 사용하여 데브섹옵스 파이프라인을 구성하는 것이 좋습니다.

(2) 네트워크 트래픽 분리

동일한 쿠버네티스 클러스터에서 서로 다른 애플리케이션을 실행하면 특정 애플리케이션이 인접 애플리케이션을 공격할 위험이 있습니다. 네트워크 규칙을 통해 인바운드, 아웃바운드 트래픽을 제한함으로써 트래픽 공격을 방어할 수 있도록 해야 합니다.

다음과 같이 네트워크 규칙을 설정해 아웃바운드 트래픽을 제한하여 네트워크를 분리할 수 있습니다.

(3) 파드 보안을 위한 컨텍스트(Context) 적용

파드를 생성할 때 파드와 볼륨에 대한 보안 컨텍스트(Security Context) 기능을 적용할 것을 권장합니다. 파드에 과도한 권한을 부여하면 접근하지 말아야 할 리소스에 접근하게 되어 보안 사고를 일으킬 수 있습니다. 보안 컨텍스트를 통해 불필요한 루트와 커널 접근을 방지할 수 있습니다. 사용 가능한 몇 가지 중요 매개 변수는 다음과 같습니다.

아래는 보안 컨텍스트를 runAsNonRoot로 설정하여 컨테이너가 루트로 실행되는 것을 방지하는 예시입니다.

(4) 파드의 보안 관련 기능 사용 제한

클러스터 관리자는 하나 이상의 PodSecurityPolicy를 작성해 쿠버네티스가 제공하는 보안 관련 기능 사용을 제한할 수 있습니다. PodSecurityPolicy는 사용자가 파드에서 이용할 수 있는 보안 기능을 제어하는 클러스터 수준의 리소스입니다. '클러스터 수준의 리소스'라 함은 정책이 클러스터 전체에 적용된다는 의미입니다. PodSecurityPolicy 리소스의 정책 작업은 Admission Control Plugin에 의해 수행됩니다. PodSecurityPolicy를 적용함으로써 컨테이너가 바인드할 수 있는 포트 범위, 네임 스페이스를 제한해 클러스터를 보호합니다.

마치며

클라우드 네이티브 생태계가 발전하면서 클라우드의 사용 방식이 근본적으로 바뀌고 있습니다. 보안 역시 기존의 엔드포인트 중심에서 클라우드 전체의 라이프 사이클을 아우르는 방향으로 패러다임이 변화하는 중입니다. 그 중심에 쿠버네티스가 있습니다. 기업의 개발자·데브옵스 엔지니어·IT 운영자는 앞서 소개한 사례를 참고하여 쿠버네티스 보안에 만전을 기해야 합니다. 이를 통해 컨테이너 중심의 애플리케이션을 안전하게 보호할 수 있음은 물론 궁극적으로 데브섹옵스 여정의 기초를 탄탄하게 다질 수 있을 것입니다.


References
[1] https://securityaffairs.cp/wordpress/120807/security/kubernetes-quidance.html
[2] https://kubernetes.io/docs/concepts/policy/pod-security-policy/
[3] https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
[4] https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/

제이쿼리(jQuery)를 아직도 사용하나요? - 제이쿼리의 현재와 미래

https://www.samsungsds.com/kr/insights/jQuery.html

제이쿼리(jQuery)란

제이쿼리는 웹사이트에 자바스크립트를 쉽게 활용할 수 있도록 도와주는 오픈소스 기반의 자바스크립트 라이브러리입니다. “write less, do more(적게 작성하고, 많은 것을 하자)”라는 모토로 2006년 미국의 SW 개발자 존 레식(John Resig)이 발표하였습니다.

웹 표준 API의 확장

W3C(World Wide Web Consortium)·WHATWG(Web Hypertext Application Technology Working Group)와 같은 단체의 노력으로 웹 표준은 끊임없이 발전해왔습니다. 그러나 그 노력의 이면에는 제이쿼리와 같은 라이브러리를 사용해야만 활용 가능했던 편의 기능을 브라우저에서 기본 API로 제공하는 것도 포함되어 있었습니다. 단적인 예가 Fetch API입니다. 이 API는 제이쿼리에서 가장 널리 사용되던 jQuery.ajax() 메소드 수준의 편의성과 유연성을 제공합니다. 이와 같이 높은 기능성을 갖춘 웹 표준 API가 늘어나면서 제이쿼리의 입지가 약화하고 있습니다.

웹브라우저 환경의 변화

제이쿼리가 본격적으로 사용되기 시작한 2007~2008년은 인터넷 익스플로러(Internet Explorer)가 전 세계 웹브라우저 시장의 60% 이상을 점유하면서 절대 강자로 군림하고 있었습니다. 인터넷 익스플로러는 마이크로소프트의 다른 애플리케이션처럼 안정적인 변화를 추구하여 버전 업그레이드가 느렸으며 데스크톱 기반의 윈도우(Windows) 환경에 주력하였습니다. 따라서 생산성과 가독성이 높은 간결한 코드를 작성하기 위해서는 제이쿼리가 필요했습니다. 그러나 2008년 크롬(Chrome)이 등장하면서 브라우저 시장은 일대 변혁을 맞이했습니다. 윈도우, 맥(Mac), 리눅스(Linux) 등의 데스크톱 OS뿐만 아니라 안드로이드 등의 모바일 OS도 지원하는 크롬은 인터넷 익스플로러의 점유율을 빠르게 잠식했으며, 2013년 이후 줄곧 글로벌 시장점유율 1위를 지키고 있습니다. 크롬은 여러 부분에서 인터넷 익스플로러와 달랐습니다. 성능이 더 우수한 렌더링 엔진을 탑재하였고 빠른 버전 업그레이드를 위해 웹 표준을 신속하게 반영하였습니다. 그 결과 제이쿼리와 같은 라이브러리를 사용하지 않고도 양질의 웹 애플리케이션 구현이 가능해졌습니다.

가상 돔(Virtual DOM)을 사용하는 라이브러리의 등장

웹페이지는 브라우저상에서 돔(DOM, Document Object Model)이라는 표준 형식으로 파싱(Parsing)되어 표현됩니다. 따라서 사용자 조작에 맞춰 동적으로 변화하는 대화형 웹(Interactive Web)을 구현하기 위해서는 돔 조작이 필수적입니다. 그런데 대부분의 브라우저에서 돔 조작이 발생할 때마다 배치나 화면 표시에 많은 연산을 발생시키다 보니 조작이 빈번해질수록 브라우저 성능이 낮아지는 문제가 있었고 이는 개발자의 창의력을 저해하는 요소로 작용하였습니다. 이러한 이슈를 해결하기 위해 자바스크립트 라이브러리의 하나인 리액트(React)는 가상 돔을 채용하여 대중화시켰습니다. 리액트를 활용하면 메모리에 가상 돔을 구성하여 실제 돔과의 차이점을 비교하고 변경된 부분을 실제 돔에 적용할 수 있습니다. 이러한 방식은 성능이 뛰어나고 화려한 웹페이지를 비교적 손쉽게 제작할 수 있도록 해 개발자들에게 크게 환영받았습니다. 이후 등장한 뷰(Vue.js) 등의 프레임워크와 라이브러리도 가상 돔을 적극 채용하고 있습니다.

가상 돔을 사용하는 라이브러리가 많아질수록 돔을 직접 조작하는 제이쿼리의 필요성이 줄어듭니다. 스테이트 오브 자바스크립트(https://2019.stateofjs.com/ko)에서 공개한 2019년 웹 프론트엔드 프레임워크 선호도 조사 결과에 따르면 개발자들은 제이쿼리보다 리액트·뷰와 같은 가상 돔 기반의 라이브러리에 매우 긍정적인 반응을 보이는 것으로 나타났습니다.

제이쿼리(jQuery)의 위상이 하락하는 요인으로 높은 기능성을 갖춘 웹 표준 API의 증가, 인터넷 익스플로러의 쇠락, 가상 돔을 사용하는 라이브러리 선호 등을 들 수 있습니다.

제이쿼리의 대응 전략

이 같은 웹 프론트엔드 환경의 변화에 따라 제이쿼리는 은퇴를 준비하고 있을까요 결론부터 말하면 "아니오"입니다. 제이쿼리가 속해있는 OpenJS재단(https://openjsf.org)은 제이쿼리를 노드JS(Node.js) 등과 함께 "영향력 있는 프로젝트(Impact Projects)"로 분류하였습니다. 즉, 제이쿼리는 이미 성장 목표에 도달했으며 개발, 유지보수 및 장기 지원의 지속적인 주기를 보장하는 성숙한 프로젝트로 관리하겠다는 것입니다. 재단의 이 같은 정책 방향과 제이쿼리 차기 버전(4.x)의 마일스톤을 바탕으로 유추해보건대 제이쿼리는 급격한 변화를 시도하지 않고 일반적인 자바스크립트 환경에서 자신의 영향력을 공고히 해나가는데 주력할 것으로 예상됩니다. 이러한 대응 전략을 엿볼 수 있는 제이쿼리 차기 버전(4.x)의 주요 마일스톤은 다음과 같습니다.

경량화

자바스크립트는 컴파일(Compile)을 하지 않고 바로 실행시킬 수 있는 스크립트 언어로 파일 크기가 커질수록 전송·파싱·실행에 지연이 발생하여 페이지 초기화 성능을 떨어뜨리기 때문에 자바스크립트 라이브러리들은 용량을 줄이기 위해 노력합니다. 제이쿼리는 경량의 라이브러리로 정평이 나 있습니다. 최신 버전인 v3.5.1의 압축된(Minified) 버전은 용량이 89KB 정도이며 에이잭스(Ajax)와 애니메이션 기능이 제외된 슬림(Slim) 버전의 경우 72KB에 불과합니다.(심지어 Gzip 압축 전송 시 30KB로 줄어듭니다) 하지만 제이쿼리는 여기에 만족하지 않고 차기 버전에서 다시 한 번 경량화를 시도하고 있으며 세부 내용은 다음과 같습니다.

인터넷 익스플로러11 미만 버전의 지원 중단
마이크로소프트는 윈도우 서버 및 임베디드 버전을 포함하여 2020년 1월부터 인터넷 익스플로러10 이하 버전에 대한 기술지원을 완전히 종료했습니다. 이로써 인터넷 익스플로러는 현재 11 버전만 기술지원이 이루어지고 있습니다. 제이쿼리 역시 국가별 점유율을 고려하여 인터넷 익스플로러11을 제외한 다른 버전의 지원을 중단할 예정입니다. 따라서 제이쿼리 차기 버전부터는 인터넷 익스플로러10 이하용 호환 코드들이 모두 제거되며 기존에 제공되던 API 중 일부가 "Deprecated(사용을 권장하지 않음)" 처리되거나 삭제됩니다.

시즐(Sizzle)의 내재화
제이쿼리가 지금의 위치에 도달하는 데는 CSS 선택자 엔진(Selector Engine)인 시즐(Sizzle)의 역할이 컸습니다. 인터넷 익스플로러8 버전이 등장하기 전까지 개발자들은 엘리먼트(Element)를 찾는데 getElementById와 같은 길고 복잡한 API를 사용할 수 밖에 없었기 때문에 복잡한 돔 구조에서 엘리먼트 몇 개만 찾으려고 해도 코드가 난잡해지기 일쑤였습니다. 하지만 시즐의 경우 CSS 작성 시 흔히 사용하는 선택자(Selector)와 시즐만의 확장 선택자를 이용하여 아무리 복잡한 돔 구조라도 짧은 코드로 손쉽게 엘리먼트를 찾아낼 수 있었습니다. 제이쿼리는 1.3버전부터 시즐을 포함하여 배포하였으며 이는 사람들이 제이쿼리를 호평하는 중요한 이유가 되었습니다. 하지만 동일한 역할을 하는 querySelector API가 인터넷 익스플로러8 이후의 모든 브라우저에서 지원되기 시작하였고 CSS 표준에서 선택자에 대한 지원도 강화되면서 표준 선택자만으로도 엘리먼트 선택이 가능해져 시즐의 필요성이 점차 줄어들었습니다. 결국 OpenJS재단은 시즐의 수명이 다한 것으로 판단해 “명예 프로젝트(Emeritus Projects)”로 분류하였습니다. 이에 따라 제이쿼리는 시즐을 내재화하였으며 점진적으로 시즐만의 확장 기능을 제거하고 필수 기능만 지원하는 형태로 수정할 계획입니다.

브라우저 호환 기능 추가

제이쿼리는 특정 브라우저만 제공하는 기능을 타 브라우저에서도 사용할 수 있도록 하는 브라우저간 호환 기능을 제공하고 있습니다. 예를 들면 비동기 작업 수행을 위한 표준 기능인 Promise는 인터넷 익스플로러에서 지원하지 않지만 제이쿼리의 Deferred를 이용하면 이에 상응하는 기능 구현이 가능합니다. 제이쿼리 차기 버전은 현재 크롬만 지원하는 기능인 “신뢰할 수 있는 타입(Trusted type)”을 모든 브라우저에서 사용 가능하도록 할 계획입니다. "돔 기반 교차 사이트 스크립팅(DOM XSS)”은 가장 일반적인 웹 보안 취약성 중 하나인데 “신뢰할 수 있는 타입”은 이러한 취약성을 제거할 수 있도록 작성, 보안 검토 및 유지 관리하는 도구를 제공합니다. 앞으로 제이쿼리를 통한 돔 엘리먼트 조작 시 신뢰하는 HTML인지 확인이 가능해지는 등 보안이 한층 더 강화될 것으로 예상됩니다.

YouTube > Data API >  안내 > 인증 자격증명 가져오기
https://developers.google.cn/youtube/registering_an_application?hl=ko

 : YouTube Data API을(를) 사용하려면 애플리케이션에 인증 자격증명 정보가 포함되어 있어야 합니다. 
   이 문서에서는 Google API   Console 콘솔이 지원하는 다양한 인증 자격증명 유형에 대해 설명합니다. 
   또한 프로젝트 관련 인증 자격증명을 찾거나 만드는 방법에 대해서도 설명합니다.
   

프로젝트 만들기 및 API 서비스 선택하기

1.Open the Credentials page in the API Console. ( https://console.cloud.google.com/apis/credentials?hl=ko )

OAuth는 위에서 살펴봤듯, 크게 3단계로 나뉘어져 있다.

1. 서비스를 등록하는 과정
   • 네이버에 자사 서비스 등록하기
   • 이 과정에서 redirect_uri 등을 합의하기
2. 토큰을 받기 위한 과정
   • 사용자를 네이버 로그인 페이지로 이동시키기
   • 네이버가 사용자를 우리 서비스로 리다이렉트 시키기
3. 토큰을 이용해 정보를 요청하는 과정

유튜브 채널 분석 정보 관련

1.Youtube 로그인
2.오른쪽 상단에 프로필 아이콘 클릭 후, 'Youtube 스튜디오' 선택 
3.'Youtube 스튜디오'에서 왼쪽 메뉴 중 '분석' 메뉴 선택

또는  로그인 후 www.youtube.com/analytics 접속.

분석메뉴에서 ‘더보기’ 들어가면 csv 다운로드 가능합니다.  

해당 년도 주차별 달력 날짜 정보, ISO 8601

https://ko.wikipedia.org/wiki/ISO_8601

weeknum  정보 

ISO 8601 Data elements and interchange formats - Information interchange - Representation of dates and times은 날짜와 시간과 관련된 데이터 교환을 다루는 국제 표준이다. 이 표준은 국제 표준화 기구(ISO)에 의해 공포되었으며 1988년에 처음으로 공개되었다. 이 표준의 목적은 날짜와 시간을 표현함에 있어 명백하고 잘 정의된 방법을 제공함으로써, 날짜와 시간의 숫자 표현에 대한 오해를 줄이고자함에 있는데, 숫자로 된 날짜와 시간 작성에 있어 다른 관례를 가진 나라들간의 데이터가 오갈때 특히 그렇다.

일반적으로, ISO 8601은 그레고리력 (proleptic Gregorian도 가능)에서의 날짜와 (부가적으로 시간대 정보를 포함하는) 24시간제에 기반하는 시간, 시간 간격(time interval) 그리고 그들의 조합에 대한 표현과 형식에 적용된다. 이 표준은 표현할 날짜/시간 요소에 어떠한 특정 의미도 할당하지 않는다; 그 의미는 사용 맥락에 따라 달라질 것이다. 추가로, 표현될 날짜와 시간은 표준 내에서의 지정된 의미의 숫자(예를 들자면, 중국 달력의 년도 이름)가 아니고서는 단어를 포함할 수 없으며 단어들은 문자(예: 이미지, 소리)를 사용하지 않는다.

교환을 위한 표현에서, 날짜와 시간은 재배치되어서, 가장 큰 시간 용어(년도)가 왼쪽에 놓이며 각각의 더 작은 용어들은 이전 용어의 우측에 놓이게 된다. 표현은 아라비아 숫자와 표준 내에서 특정 의미를 제공하는 ("-", ":", "T", "W" 그리고 "Z"와 같은) 어떤 문자들로 작성되어야 한다. 그것이 의미하는 바는, "January" 혹은 "Thursday"처럼 날짜의 일부를 작성하는 어떤 평범한 방법이 교환 표현에서는 허용되지 않는다는 것이다.

Week date 표현은 위 박스에서 볼 수 있는 형식 중 하나다. YYYY는 전통적인 그레고리력의 연도와는 살짝 다른 ISO 주수 연도를 가리킨다. Www는 문자 W를 접두사로 하는 주수로, W01부터 W53까지며 월요일이 시작, 일요일이 끝이다.

* 주의 서로 대등하고 공존 가능한 명세가 존재:

- 01 주 내 연도의 첫번째 목요일이 존재 (공식 ISO 정의),
- 01 주 내 1월 4일이 존재,
- 시작 연도 내 01 주의 일 대부분(4일 이상)을 가진 첫번째 주, 그리고
- 12월 29일부터 1월 4일까지의 기간 내에 있는 월요일로 시작하는 주.

그런 결과로, 1월 1일이 월요일, 화요일, 수요일 혹은 목요일에 있다면, 1월 1일은 01 주 내에 포함된다. 1월 1일이 금요일, 토요일 혹은 일요일이라면, 전년도의 52 주 혹은 53 주에 포함된다 (00주는 없다). 12월 28일은 항상 해당 연도의 마지막 주에 포함된다.

주수(week number)는 목요일을 카운트하여 기술 가능하다: 즉, 12 주는 연도의 12번째 목요일이다.

ISO 주수 매기기 연도는 01 주의 첫번째 날(월요일)에서 시작하며 새로운 ISO 연도 전의 일요일에 끝이 난다(그러므로 겹치거나 격차가 나지 않는다). 연도는 꽉찬 52 혹은 53 주로 구성된다. ISO 주수 매기기 연도의 번호는 (ISO 주수 매기기 이전 연도의 끝인) 전통적인 그레고리력 연도 시작점의 금, 토, 일 혹은 토, 일 혹은 그냥 일요일과 (ISO 주수 매기기 다음 연도의 01 주인) 전통적인 그레고리력 연도의 끝점의 월, 화, 수 혹은 월, 화 혹은 그냥 월요일의 전통 그레고리력 연도의 번호로부터 벗어난다. 목요일에 대해, ISO 주수 매기기 연도 번호는 항상 전통적인 그레고리력 연도 번호와 같다.

예: 2008년 12월 29일 월요일은 "2009-W01-1"로 쓰여진다
    2010년 1월 3일 일요일은 "2009-W53-7"로 쓰여진다

L2 스위치 와 L3 스위치