보허(Insurance)는 재정적 손실로부터 보호하는 수단이다. 우발적이거나 불확실한 손실의 위험에 대비하기 위해서 사용하는 일종의 위험 관리(risk management)수단이다.보험을 제공하는 기관을 보험사, 보험회사 또는 보험업자라고(underwriter) 한다. 보험을 구매하는 개인 또는 단체는 피보험자 혹은 보험계약자라고 한다. 보험 거래에는 보험 적용자가 손실에 대한 보상을 약속하겠다는 약속과 이에 대한 대가로 보험사에 얼마를 지불하는 형태로 보증된다. 손실은 재정적 일 수도 있고 아닐 수도 있으나 재정적 조건으로 환원될 수 있어야 한다.
CSA(Cloud Security Alliance)의 최신 보고서에 따르면 클라우드 컴퓨팅과 관련된 가장 큰 위험은 설정(configuration)과 인증(Authentication)에 관련된 문제다. 이전 보고서에서 시스템 취약성(vulnerabilities)과 멀웨어(malware)를 지적했던 것에 비하면 새로운 방향전환이라 할 만하다.기업은 서버를 포함한 디지털 자산과 애플리케이션 그리고 모든 종류의 데이터들을 클라우드로 지속적으로 옮기고 있다. 클라우드는 운영성, 확장성, 접근및 관리 등에 있어서 많은 이점을 가지고 있다. 대부분의 경우에는 클라우드 시스템을 신뢰하고 호스팅하기에 충분하며 사용자는 이 이점을 누릴 수 있다. 그러나 다른 모든 기술과 마찬가지로 클라우드의 사용에도 위험이 있다. 이 문서는 인증과 설정관련 문제로 시작하는 11개의 중요 위협과 이들 위협에 대한 대응 방안을 담고 있다. 대응은 AWS를 기준으로 한다.
영업보험료는 보험계약자에게 받는 보험료로 총보험료라고도 한다. "영업보험료 = 위험보험료 + 저축보험료 + 사업비" 로 구성된다.순보험료는 "위험보험료 + 저축보험료"로 구성된다. IFRS에서 저축보험료는 매출에게 제외되므로 외형축소가 예상된다. 부가보험료는 사업비로 전체 영업보험료 중 보장성상품은 30~50% 전체 영업보험료 중 연금상품은 15% 전체 영업보험료 중 저축상품은 10%
(2020년 1월)지금으로 부터 약 13년전 구글은 제품 생산 관리 방식을 바꾸기로 결졍한다. 개발팀은 새로운 기능을 만들어서 제품에 적용하는데 집중했지만 운영 그룹은 만들어진 제품을 안정적으로 유지하려고 노력했다. 두 조직의 이해가 상충했다. 이러한 긴장은 다른 경험, 기술 세트, 평가 기준의 차이로 발생했다.구글의 운영 책임자 중 한명인 Ben Treynor는 두 그룹간의 격차를 해소하려고 노력했으며 그결과 혁신적인 솔루션을 생각했다. 시스템 관리자만으로 구성된 Ops 팀을 구성하는대신에 연구/개발 배경과 사고방식을 갖춘 소프트웨어 엔지니어로 구성된 팀을 만드는 것이다. 이 팀은 개발 그룹과 작업하는 방식을 풍부하게 하며, 개발과 운영 모두에 최적화할 수 있는 목표를 수립하고 솔류션을 자동화 할 수 있다. 시스템이 클라우드화 된다는 것은 시스템이 소프트웨어화 된다는 의미다. 이러한 조직 구성은 클라우드 환경에서의 품질관리에 새로운 방향을 제시했다.
증권형 토큰(Security token)는 주식, 채권, 부동산 등 실물자산을 암호화폐에 고정한 디지털 자산으로 증권형 암호화폐라고도 한다. 참고로 암호화폐는 지불형, 유틸리티형, 증권형으로 분류 할 수 있다. 1. 지불형 1. 유틸리티형 1. 증권형 증권형 토큰 공개(STO)란 토큰화된 디지털 증권을 공개적으로 판매하는 것을 의미한다. 주식과 채권 같은 실제 금융 자산을 거래하는데 사용 할 수 있으며 거래 내용은 블록 체인원장시스템을 사용해서 저장하고 확인 할 수 있다.
AWS 클라우드는 하나 이상의 어카운트로 구성될 수 있다. 프로젝트 별로 어카운트를 만들 수 있으며, 각 프로젝트는 다시 개발팀, QA, 운영팀, 보안팀 과 같은 역할별로 어카운트를 만들 수 있을 것이다. AWS Organization을 이용해서 여러 개의 계정을 통합해서 관리 할 수 있다. 여기에는 예산, 보안과 규정 준수 요건을 충족하기 위한 계정 관리, 통합 결제 기능등을 포함한다.아래 다이어 그램은 4개의 OU(Organizational unit)을 가지는 7개의 계정으로 구성된 기본 조직을 묘사하고 있다.
에서 Organization을 만들고 Account를 등록하는 방법에 대해사 살펴봤다. 이를 응용해서 멀티어카운트를 관리하는 방법을 살펴보려 한다. Enterprise 환경을 위한 AWS Account Setup가이드로 봐주면 되겠다.Enterprise 환경에서 AWS Account의 설정을 위해서 필요한 기본 요구사항을 살펴보겠다. 어카운트 설정은 단순해보이지만(그낭 카드만 등록하면 되지 않나?) 계정이 증가함에 따라 머리가 아파진다. 일관적으로 계정을 관리할 수 있도록 미리 준비를 해둬야 한다. AWS Organization과 프로젝트/조직 별 계정, 배포단계(개발, 스테이징, 프러덕트), 역할별(어드민, 보안 ...) 계정을 이용한 베스트 프렉티스를 찾아보자.
Go 언어를 이용해서 Dynamodb에 CRUD하는 방법을 살펴볼 것이다. 우분투 리눅스 19.04 Go version 1.12 AWS Cloud 서울 리전 데이터베이스 DynamoDB는 AWS의 관리형 NoSQL 데이터베이스다. 서버가 필요 없는 서버리스(ServerLess) 환경을 제공한다. 개발자는 가용성, 확장, 성능 등에 대한 고민 없이 개발 할 수 있다. 개발자는 AWS DynamoDB에 접근 할 수 있는 Credential을 가지고 있어야 한다. 문서를 참고하자.
AWS CodePipeline는 애플리케이션 릴리즈 파이프라인의 자동화를 위해서 사용하는 완전관리형 CICD 서비스다. 사용자는 CodePipeline를 GitHub, GitLab, BitBucket, CodeCommit 등과 연결해서 릴리즈 파이프라인을 구성 할 수 있다. 나는 ECS 애플리케이션을 CodePipeline를 통해서 개발&배포 하는 환경을 구성 할 계획이다. 몇 몇 부분은 AWS 웹 콘솔로 작업을 하겠으나 AWS CLI 위주로 작업을 할 것이다. 이유는 웹 콘솔 스크린샷 찍기 귀찮아서 이다.
19 POSTS HERE
Gig economy
일반인이 자신이 원하는 날짜와 시간, 지역에서 제품 배송 업무를 하고 수입을 얻을 수 있도록 한 시스템. 기본적으로 지역기반
insurance
보허(Insurance)는 재정적 손실로부터 보호하는 수단이다. 우발적이거나 불확실한 손실의 위험에 대비하기 위해서 사용하는 일종의 위험 관리(risk management)수단이다.보험을 제공하는 기관을 보험사, 보험회사 또는 보험업자라고(underwriter) 한다. 보험을 구매하는 개인 또는 단체는 피보험자 혹은 보험계약자라고 한다. 보험 거래에는 보험 적용자가 손실에 대한 보상을 약속하겠다는 약속과 이에 대한 대가로 보험사에 얼마를 지불하는 형태로 보증된다. 손실은 재정적 일 수도 있고 아닐 수도 있으나 재정적 조건으로 환원될 수 있어야 한다.
Top 11 Threats in Cloud Computing and How to Prevent Them for AWS
CSA(Cloud Security Alliance)의 최신 보고서에 따르면 클라우드 컴퓨팅과 관련된 가장 큰 위험은 설정(configuration)과 인증(Authentication)에 관련된 문제다. 이전 보고서에서 시스템 취약성(vulnerabilities)과 멀웨어(malware)를 지적했던 것에 비하면 새로운 방향전환이라 할 만하다.기업은 서버를 포함한 디지털 자산과 애플리케이션 그리고 모든 종류의 데이터들을 클라우드로 지속적으로 옮기고 있다. 클라우드는 운영성, 확장성, 접근및 관리 등에 있어서 많은 이점을 가지고 있다. 대부분의 경우에는 클라우드 시스템을 신뢰하고 호스팅하기에 충분하며 사용자는 이 이점을 누릴 수 있다. 그러나 다른 모든 기술과 마찬가지로 클라우드의 사용에도 위험이 있다. 이 문서는 인증과 설정관련 문제로 시작하는 11개의 중요 위협과 이들 위협에 대한 대응 방안을 담고 있다. 대응은 AWS를 기준으로 한다.
생명보험업 이해
영업보험료는 보험계약자에게 받는 보험료로 총보험료라고도 한다. "영업보험료 = 위험보험료 + 저축보험료 + 사업비" 로 구성된다.순보험료는 "위험보험료 + 저축보험료"로 구성된다. IFRS에서 저축보험료는 매출에게 제외되므로 외형축소가 예상된다. 부가보험료는 사업비로 전체 영업보험료 중 보장성상품은 30~50% 전체 영업보험료 중 연금상품은 15% 전체 영업보험료 중 저축상품은 10%
DevOps와 SRE의 다른 점
(2020년 1월)지금으로 부터 약 13년전 구글은 제품 생산 관리 방식을 바꾸기로 결졍한다. 개발팀은 새로운 기능을 만들어서 제품에 적용하는데 집중했지만 운영 그룹은 만들어진 제품을 안정적으로 유지하려고 노력했다. 두 조직의 이해가 상충했다. 이러한 긴장은 다른 경험, 기술 세트, 평가 기준의 차이로 발생했다.구글의 운영 책임자 중 한명인 Ben Treynor는 두 그룹간의 격차를 해소하려고 노력했으며 그결과 혁신적인 솔루션을 생각했다. 시스템 관리자만으로 구성된 Ops 팀을 구성하는대신에 연구/개발 배경과 사고방식을 갖춘 소프트웨어 엔지니어로 구성된 팀을 만드는 것이다. 이 팀은 개발 그룹과 작업하는 방식을 풍부하게 하며, 개발과 운영 모두에 최적화할 수 있는 목표를 수립하고 솔류션을 자동화 할 수 있다. 시스템이 클라우드화 된다는 것은 시스템이 소프트웨어화 된다는 의미다. 이러한 조직 구성은 클라우드 환경에서의 품질관리에 새로운 방향을 제시했다.
Security token offering
증권형 토큰(Security token)는 주식, 채권, 부동산 등 실물자산을 암호화폐에 고정한 디지털 자산으로 증권형 암호화폐라고도 한다. 참고로 암호화폐는 지불형, 유틸리티형, 증권형으로 분류 할 수 있다. 1. 지불형 1. 유틸리티형 1. 증권형 증권형 토큰 공개(STO)란 토큰화된 디지털 증권을 공개적으로 판매하는 것을 의미한다. 주식과 채권 같은 실제 금융 자산을 거래하는데 사용 할 수 있으며 거래 내용은 블록 체인원장시스템을 사용해서 저장하고 확인 할 수 있다.
AWS Organizations를 이용한 멀티플 어카운트 관리
AWS 클라우드는 하나 이상의 어카운트로 구성될 수 있다. 프로젝트 별로 어카운트를 만들 수 있으며, 각 프로젝트는 다시 개발팀, QA, 운영팀, 보안팀 과 같은 역할별로 어카운트를 만들 수 있을 것이다. AWS Organization을 이용해서 여러 개의 계정을 통합해서 관리 할 수 있다. 여기에는 예산, 보안과 규정 준수 요건을 충족하기 위한 계정 관리, 통합 결제 기능등을 포함한다.아래 다이어 그램은 4개의 OU(Organizational unit)을 가지는 7개의 계정으로 구성된 기본 조직을 묘사하고 있다.
AWS Account Best Practice
에서 Organization을 만들고 Account를 등록하는 방법에 대해사 살펴봤다. 이를 응용해서 멀티어카운트를 관리하는 방법을 살펴보려 한다. Enterprise 환경을 위한 AWS Account Setup가이드로 봐주면 되겠다.Enterprise 환경에서 AWS Account의 설정을 위해서 필요한 기본 요구사항을 살펴보겠다. 어카운트 설정은 단순해보이지만(그낭 카드만 등록하면 되지 않나?) 계정이 증가함에 따라 머리가 아파진다. 일관적으로 계정을 관리할 수 있도록 미리 준비를 해둬야 한다. AWS Organization과 프로젝트/조직 별 계정, 배포단계(개발, 스테이징, 프러덕트), 역할별(어드민, 보안 ...) 계정을 이용한 베스트 프렉티스를 찾아보자.
GoLang과 DynamoDB
Go 언어를 이용해서 Dynamodb에 CRUD하는 방법을 살펴볼 것이다. 우분투 리눅스 19.04 Go version 1.12 AWS Cloud 서울 리전 데이터베이스 DynamoDB는 AWS의 관리형 NoSQL 데이터베이스다. 서버가 필요 없는 서버리스(ServerLess) 환경을 제공한다. 개발자는 가용성, 확장, 성능 등에 대한 고민 없이 개발 할 수 있다. 개발자는 AWS DynamoDB에 접근 할 수 있는 Credential을 가지고 있어야 한다. 문서를 참고하자.
AWS CodePipeline를 이용한 CICD 화경 구성
AWS CodePipeline는 애플리케이션 릴리즈 파이프라인의 자동화를 위해서 사용하는 완전관리형 CICD 서비스다. 사용자는 CodePipeline를 GitHub, GitLab, BitBucket, CodeCommit 등과 연결해서 릴리즈 파이프라인을 구성 할 수 있다. 나는 ECS 애플리케이션을 CodePipeline를 통해서 개발&배포 하는 환경을 구성 할 계획이다. 몇 몇 부분은 AWS 웹 콘솔로 작업을 하겠으나 AWS CLI 위주로 작업을 할 것이다. 이유는 웹 콘솔 스크린샷 찍기 귀찮아서 이다.