클라우드 컴퓨팅 관련 이슈

이다연·2021년 6월 7일
0

WEB

목록 보기
7/7

1. 물리적인 데이터 센터

  • 네이버 클라우드 플랫폼 NCP의 '각': 지진 안전 설계, 친환경 기술로 서버 열 내리는 기술 적용

  • AWS의 데이터 센터 : https://www.youtube.com/watch?v=94PO2-TL4Vs
    Businesses hire AWS, why so? renting out computer resources and dealing with complexities managing computers
    racks of computers!

Pros: it offers speed, flexiblity, security, savings to the world business
Cons: uses massive amount of power, waiting for a spike in traffic, 96% of the time, it's doing nothing

2. 비용 절감

  • 클라우드 기업은 TCO계산기를 제공함
    온프레미스와 퍼블릭 클라우드를 비용 측면에서 비교할 때
    온프레미스의 자본 구입 비용과 운영 유지비를 모두 고려한 TCO(total coast of ownership 총 소유비용)와 클라우드 사용비용을 비교해야 함.
  • 요금 절약을 위한 인스턴스 운영 기준을 만들고, Auto-scaling 서비스를 이용함

3. 클라우드 사고

  • 클라우드에서 실행되던 회사 서비스가 중단된다면?
  • 대비책: SLA(Service Level Agreement, 서비스 수준 계약)
    “월 대금청구주기 동안(저번 달 서비스 요금 납부일 ~ 이번 달 서비스 요금 납부일) 최소 99.99%의 월별 가동시간비율을 제공해야 한다”
    (31일 X 24시간 X 60분) 중에서 (100%-99.99%)의 0.01% 즉, 4.464분 정도까지는 서비스가 이용불가인 상태이더라도 AWS는 책임을 지지 않는다는 뜻
    ‘서비스 크레딧’이라는 이름으로 돌려주는 것으로 되어 있음. 서비스 이용 불가로 피해를 본 기업이 해당 사항을 정해진 양식대로 AWS에 알려야 함
    • 실제 사고 사례
      2018년 11월 말에 AWS의 서울 리전에서 약 1시간 30분 정도 이상이 생겨 AWS를 이용하던 쿠팡, 야놀자 등의 서비스가 이용 불가가 됨. 서울 리전의 데이터센터에서 DNS(도메인 네임 서버) 설정 오류가 발생. DNS란 문자열로 된 외우기 쉬운 사이트 주소를 쳤을 때 그것을 123.12.456 같은 ip 주소로 변환해서 사이트의 서버를 찾을 수 있도록 도와주는 서비스. 이 DNS를 제공하는 컴퓨터가 고장나면 아무리 맞는 주소를 쳐도 원하는 사이트에 접속할 수 없음

고객이 할 수 있는 일

특정 가용 영역(AZ)에서 문제가 생겨도 대비할 수 있도록, 리전 내의 모든 가용 영역에 문제가 생겨도 대비할 수 있도록 인프라를 구축해놓아야 함

1) High Availability Architecture(고가용성 아키텍처)
서비스의 가용성을 최대한 높이기 위한 방식으로 설계된 인프라의 구조

2) 멀티 클라우드
여러 클라우드 회사의 서비스를 동시에 사용하는 방법. 하지만 각 클라우드 서비스에 관한 전문 인력을 구하는 것이 어렵고, 여러 시스템을 연동하는 추가적인 노력이 필요하기 때문에 쉬운 일은 아님

‘멀티 클라우드’ + ‘하이브리드 클라우드(온프레미스 + 퍼블릭 클라우드)’ 방식까지 결합하면 높은 가용성을 보장하는 인프라를 구축할 수 있음. 비용 문제만 해결된다면 가장 이상적인 방식

4. 데이터 보안

클라우드의 ‘공동 보안 책임 모델’ (Shared Responsibility Model)

보안 책임을 고객과 클라우드 서비스 제공 기업이 나눠가진다는 모델

도둑이 몰래 AWS의 데이터 센터로 침입해서 서버를 훔쳐가거나
인스턴스가 작동하고 있는 물리적 컴퓨터 자체를 해킹하면 
이를 막지 못한 AWS의 책임이지만 

인스턴스 안에 취약점이 많은 옛날 프로그램을 업데이트하지 않은 채로 그대로 둬서 해킹을 당하거나
들어오는 네트워크 트래픽을 제한할 수 있는 방화벽 설정 등을 하지 않아서
누군가가 무단으로 로그인을 하거나
특정 인스턴스를 서버로 사용할 때 암호화 방식을 사용하지 않아서
(예를 들어 HTTPS를 사용해야 하는데 HTTP를 사용하는 경우 등) 
중간의 누군가가 오고가는 트래픽 내용을 훔쳐보는 경우 등은 
고객의 책임이라는 뜻

클라우드 서비스 제공 기업들은 이미 법으로 정해진 여러 보안 인증을 획득하기 위해 그 요구 조건들을 실천하려고 노력하고, 고객 기업들은 그런 보안 인증을 보고 해당 서비스의 보안성을 신뢰

고객이 해야 할 일

1) 클라우드 서비스 내에서 사용할 수 있는 보안 기능을 잘 익히고 최대한 잘 사용하기

2) 인스턴스 내부의 소프트웨어에 취약점이 없도록 업데이트 잘하기

3) 데이터 저장 및 통신 시에 암호화 적용하기

내 인스턴스가 외부의 다른 컴퓨터와 통신할 때도 데이터는 암호화된 상태로 송신 및 수신되어야 하는데요. 그래야 내 데이터가 지나가는 통로에서 다른 컴퓨터가 중간에 데이터를 보거나 조작하는 것을 막을 수 있습니다. 이걸 하는 방법은 HTTPS, SSH 등과 같은 안전한 통신 프로토콜(통신 프로토콜이란 컴퓨터 A와 컴퓨터 B가 서로 통신할 때 사용하기 위해 정해진 규약입니다)을 쓰는 겁니다. 요즘 여러 사이트를 돌아다니다 보면 거의 다 아래 그림과 같이 URL 주소 옆에 자물쇠 아이콘이 붙어있는 것을 볼 수 있습니다.

이런 URL이 붙어있는 사이트의 서버가 바로 HTTPS라고 하는 통신 프로토콜로 나의 컴퓨터와 통신하는 서버입니다. HTTPS 이전에는 HTTP라는 통신 프로토콜이 있었는데요. 이 HTTP는 데이터를 원본 그대로 보내고 받는 방식이라서 해당 데이터가 지나가는 네트워크 선에 위치한 다른 컴퓨터가 그 데이터를 몰래 보거나, 조작할 수 있다는 단점이 있었습니다. HTTPS는 HTTP Secure의 줄임말로 HTTP를 사용하지만 데이터를 암호화해서 주고받음으로써 더 안전하게 통신할 수 있도록 하는 진화된 형태의 프로토콜입니다. 오늘날 대부분의 사이트에서 이 HTTPS를 쓰고 있습니다.

클라우드와 범죄

  1. 클라우드 자체를 공격하는 경우: 계정 탈취 후 기업 중요 정보 유출

  2. 클라우드 자체가 범죄 행위에 사용되는 경우: 실제와 유사한 사이트에 정보 입력 유도, 클라우드 인스턴스를 빌려 서버 해킹하는 경우 기록이 남지 않을 수도 있음

  3. 범죄 행위의 기록이 클라우드에 남아있는 경우:
    관련 없는 사람들의 정보까지 가져오는 것을 최소화(개인정보 침해 문제)
    해외에 서버가 있는 경우(재판 관할권, 수사 협조 문제)
    암호화된 데이터 문제

profile
이다연
Dayeon Lee | Django & Python Web Developer
이전 포스트

AWS 요금 산정 방식

0개의 댓글