Cloud Computing

---

Cloud Computing

클라우드 컴퓨팅이 쓰이는 방식은 다음과 같다.

 

On-demand self-service

사용자가 필요에 따라 리소스를 추가하거나 제거할 수 있다.

 

Broad network access

모바일, 데스크톱, 메인프레임 등 다양한 장치를 통해 네트워크로 접근할 수 있다.

 

Resource pooling

여러 사용자가 리소스를 공유하며, 필요에 따라 리소스가 동적으로 재할당될 수 있다. 이 과정은 사용자에게 보이지 않게 이루어진다.

 

Rapid elasticity

고객의 요구에 따라 서비스가 자동으로 빠르게 확장되거나 축소될 수 있다.

 

Measure service

수도, 가스, 전화 서비스와 같이 사용량을 측정하여 요금을 청구할 수 있다.

---

Service Models

클라우드 컴퓨팅 서비스 모델은 다음 세 가지로 분류된다.

 

소프트웨어 서비스 (SaaS, Software as a Service)

클라우드 제공자가 고객에게 클라우드에서 실행되는 애플리케이션에 접근할 수 있는 권한을 제공한다.

예: 구글 드라이브, 마이크로소프트 365.

 

플랫폼 서비스 (PaaS, Platform as a Service)

고객이 자신의 애플리케이션을 생성하고 실행할 수 있도록 클라우드가 프로그래밍 언어와 도구를 제공한다.

예: 구글 앱 엔진, AWS Elastic Beanstalk.

 

인프라 서비스 (IaaS, Infrastructure as a Service)

클라우드 제공자가 고객이 소프트웨어를 실행할 수 있도록 처리 능력, 스토리지, 네트워크 등 컴퓨팅 리소스를 제공합니다. 예: AWS EC2, Microsoft Azure VM.

---

Deployment Models

클라우드 컴퓨팅 배포 모델은 다음 네 가지로 구분된다.

1. 프라이빗 클라우드 (Private Cloud)
   • 특정 조직에 의해 독점적으로 운영되며, 해당 조직을 위해 설계된 인프라이다.
   • 보안과 제어가 매우 중요한 경우 사용된다.
   • 예: 대기업의 내부 클라우드 시스템.
2. 커뮤니티 클라우드 (Community Cloud)
   • 공통의 필요, 관심사, 목표를 가진 여러 조직이 공유하는 클라우드이다.
   • 동일한 산업군이나 협력 관계를 가진 조직들 간에 활용된다.
   • 예: 의료 기관 간 데이터 공유 클라우드.
3. 퍼블릭 클라우드 (Public Cloud)
   • 클라우드 서비스 제공자가 소유하고, 일반 대중에게 제공되는 클라우드이다.
   • 비용 효율적이며, 많은 사용자를 수용할 수 있다.
   • 예: 구글 클라우드, AWS, Microsoft Azure.
4. 하이브리드 클라우드 (Hybrid Cloud)
   • 두 개 이상의 클라우드(퍼블릭, 프라이빗 등)를 결합하여 데이터와 애플리케이션이 클라우드 간에 원활하게 이동할 수 있도록 기술적으로 연결한 형태이다.
   • 유연성과 확장성을 제공하며, 특정 데이터는 프라이빗 클라우드에, 다른 데이터는 퍼블릭 클라우드에 저장하는 방식으로 운영된다.

---

Cloud Migration Risk Analysis

클라우드 마이그레이션 과정에서의 위험을 분석하는 주요 단계는 다음과 같다.

1. 자산 식별 (Identify assets)
   • 클라우드로 이전할 데이터, 애플리케이션, 시스템 등의 자산을 식별합니다.
2. 취약점 파악 (Determine vulnerabilities)
   • 이전하려는 자산과 관련된 보안 취약점을 평가합니다.
3. 악용 가능성 추정 (Estimate likelihood of exploitation)
   • 식별된 취약점이 악용될 가능성을 추정합니다.
4. 예상 손실 계산 (Compute expected loss)
   • 취약점이 악용될 경우 발생할 수 있는 손실을 계산합니다.
5. 새로운 통제 방안 조사 및 선택 (Survey and select new controls)
   • 보안 위험을 줄이기 위해 필요한 새로운 통제 방안을 조사하고 선택합니다.
6. 절감 효과 예측 (Project savings)
   • 클라우드로 마이그레이션하여 절감될 비용을 예측합니다.

---

Cloud Provider Assessment

고려해야 할 보안 문제:

• 인증(Authentication), 권한 부여(Authorization), 접근 제어 옵션
• 암호화 옵션(Encryption options)
• 감사 로그 기능(Audit logging capabilities)
• 사고 대응 역량(Incident response capabilities)
• 신뢰성 및 가동 시간(Reliability and uptime)

평가에 도움이 되는 리소스:

• FedRAMP: 정부 기관용 클라우드 보안 인증 프로그램
• PCI DSS: 결제 카드 산업 데이터 보안 표준
• CSA STAR: 클라우드 보안 동맹(Cloud Security Alliance)의 보안, 신뢰 및 보증 레지스트리

---

Switching Cloud Providers

 

• 비용 및 어려움
  클라우드 제공자를 변경하는 것은 비용이 많이 들고 어렵지만 때로는 긴급한 상황으로 인해 필수가 될 수 있다.
• 백업 옵션의 중요성
  클라우드 제공자를 변경해야 할 경우를 대비해 백업 옵션을 마련하는 것이 가장 좋다. 그러나 많은 클라우드 제공자는 이를 사실상 어렵게 만든다.
• SaaS, PaaS, IaaS의 이식성
  SaaS 제공자는 일반적으로 변경이 가장 어렵고 그 다음으로 PaaS가 변경이 어려우며 IaaS가 상대적으로 가장 쉽게 변경할 수 있다.

---

Security Benefits of Cloud Services

 

• Geographic diversity
  많은 클라우드 제공자가 서로 다른 지역에 데이터 센터를 운영하며 데이터를 여러 위치에 복제한다. 이는 자연 재해나 지역적 재난으로부터 데이터를 보호하는 데 도움을 준다.
• Platform and infrastructure diversity
  다양한 플랫폼과 인프라는 서로 다른 결함과 취약점을 가지므로, 단일 공격이나 오류로 인해 시스템 전체가 다운되는 가능성을 줄인다.
  클라우드 서비스를 더 큰 시스템의 일부로 활용하면 기술 스택의 다양성을 확보할 수 있다.

---

Cloud-Based Security Functions

 

• 이메일 필터링(Email filtering)
  • 이메일은 이미 다양한 SMTP 서버를 거쳐 전송되고 있기 때문에, 클라우드 기반 이메일 필터를 추가하는 것은 단순히 하나의 추가 경로를 더하는 것만큼 간단하다.
• DDoS 보호(DDoS protection)
  • 클라우드 기반 DDoS 보호 서비스는 사용자의 DNS 기록을 업데이트하여 클라우드 제공자의 서버를 사용자의 서버 앞에 프록시로 삽입한다.
  • 이러한 방식으로 대량의 공격 트래픽(플러드 공격)을 처리할 충분한 대역폭을 유지한다.
• 네트워크 모니터링(Network monitoring)
  • 클라우드 기반 솔루션은 고객이 고성능 하드웨어 요구 사항을 해결하도록 돕는다.
  • 또한 모니터링 및 사고 대응 전문성을 제공한다.

---

Cloud Storage

 

• 기본 설정
  대부분의 클라우드 스토리지 솔루션은 기본적으로 사용자 데이터를 암호화하지 않거나, 모든 고객의 데이터를 단일 키로 암호화한다. 이로 인해 강력한 기밀성을 제공하지 못한다.
• 향상된 기밀성 제공
  일부 클라우드 서비스는 사용자의 비밀번호나 기타 비밀 정보를 기반으로 사용자별 키를 생성하여 더 나은 기밀성을 제공한다.
• 최대 기밀성
  일부 클라우드 제공업체는 "아무도 신뢰하지 않는(TNO, Trust No One)" 모델을 채택하여 심지어 클라우드 제공업체도 사용자 데이터를 복호화할 수 있는 키를 보유하지 않는 방식을 구현한다.

---

Lastpass TNO Implementation

1. 사용자 입력

사용자가 LastPass 클라이언트(사용자의 컴퓨터 또는 모바일 기기에 설치된 애플리케이션)에 사용자 이름과 마스터 비밀번호를 입력한다. 마스터 비밀번호는 사용자가 직접 생성하며, 암호화와 복호화의 핵심 키 역할을 한다.

2. 클라이언트 내 해시 생성

입력된 마스터 비밀번호는 클라이언트 내부에서 PBKDF2(Password-Based Key Derivation Function 2) 알고리즘과 SHA-256 해시 함수를 사용하여 5001번 반복 처리된다.

• PBKDF2: 비밀번호를 기반으로 복잡한 키를 생성하여 brute-force 공격에 대한 보안을 강화한다.
• SHA-256: 비밀번호를 256비트의 고유한 해시값으로 변환한다.
• 이 과정에서 솔트(Salt)를 추가하여 동일한 비밀번호라도 각 사용자마다 다른 해시값을 생성한다.

결과적으로, 솔트와 해시된 마스터 비밀번호가 생성된다.

3. 서버로 사용자 인증 정보 전송

솔트와 해시된 마스터 비밀번호가 LastPass 서버로 전송되고 이 정보는 서버가 사용자 인증을 수행하는 데 사용된다.

• 서버는 입력된 해시값을 기존 데이터베이스의 값과 비교하여 사용자를 인증한다.
• 중요한 점은, 서버는 마스터 비밀번호의 원본을 알 수 없으며, 해시값만 저장한다.

4. 복호화 키 생성

사용자의 마스터 비밀번호는 클라이언트에서 첫번째 복호화과정과는 별개로 한 번 더 PBKDF2와 SHA-256 알고리즘을 사용하여 5000번 반복 처리된다.
이 과정에서 복호화 키(Decryption Key)가 생성되며, 이 키는 AES-256 암호화로 보호된 데이터베이스를 복호화하는 데 사용된다.

5. 암호화 데이터베이스 다운로드

Lastpass Server단에서는 사용자 인증이 완료되면 LastPass 서버에서 AES-256으로 암호화된 비밀번호 데이터베이스 파일이 클라이언트로 전송된다.

• 데이터베이스 파일은 클라이언트 측에서만 복호화되며 서버는 파일 내용을 볼 수 없다.

6. 데이터베이스 복호화

클라이언트는 4번단계에서 만들어둔 복호화 키를 사용하여 암호화된 데이터베이스 파일을 해독한다.

• AES-256 알고리즘은 복호화 과정에서 데이터의 기밀성을 유지하며, 매우 높은 보안 수준을 제공한다.
• 복호화된 데이터베이스는 클라이언트 애플리케이션에서만 접근할 수 있다.

7. 사용자 데이터 접근

복호화된 데이터베이스는 사용자가 저장된 비밀번호 및 정보를 열람, 추가, 수정할 수 있도록 클라이언트에서 제공된다.

• 사용자가 데이터베이스에 추가한 내용은 다시 AES-256으로 암호화되어 서버에 저장된다.

---

Boxcryptor TNO Implementation

Boxcryptor TNO (Trust No One) 구현은 파일 암호화와 복호화를 통해 사용자 데이터의 보안을 유지하며, 클라우드 스토리지 제공자와의 데이터 보호를 극대화한다. 이 구현은 파일 추가 및 암호화와 파일 검색 및 복호화라는 두 가지 주요 프로세스로 나눌 수 있다.

1. 파일 추가 및 암호화

1-1. 사용자가 파일 추가

• 사용자가 Boxcryptor 클라이언트를 통해 암호화 및 클라우드 저장소에 업로드할 파일을 추가한다.
• 이 단계는 사용자의 로컬 디바이스에서 시작된다.

1-2. 파일 키 생성

• Boxcryptor 클라이언트는 이 파일에만 적용되는 랜덤한 "파일 키"를 생성된다.
• 이 파일 키는 이후 파일 암호화 및 복호화에 사용된다.

1-3. 파일 키 암호화

• 생성된 파일 키는 사용자의 RSA 공개 키를 사용하여 암호화된다.
• RSA는 비대칭 암호화 알고리즘으로, 공개 키를 사용해 암호화한 데이터를 복호화하려면 사용자의 비밀 키가 필요하다.

1-4. 파일 암호화

• Boxcryptor는 AES 암호화 알고리즘을 사용하여 파일 자체를 암호화한다.
• AES는 대칭 암호화 알고리즘으로, 파일 키를 사용해 파일을 암호화한다.

1-5. 클라우드 저장소로 전송

• 암호화된 파일과 암호화된 파일 키가 클라우드 스토리지 제공자로 전송되고 저장된다.
• 클라우드 제공자는 파일 내용이나 파일 키를 복호화할 수 없다.

 

2. 파일 검색 및 복호화

2-1. 사용자가 파일 요청

• 사용자가 Boxcryptor 클라이언트를 통해 클라우드에 저장된 파일을 요청한다.
• 파일 요청은 파일 식별자(File Descriptor)를 사용해 이루어진다.

2-2. 클라우드에서 데이터 검색

• Boxcryptor 클라이언트는 클라우드 저장소 제공자로부터 암호화된 파일과 암호화된 파일 키를 요청하고 수신한다.
• 이 데이터는 여전히 암호화된 상태로 클라이언트로 전달된다.

2-3. 파일 키 복호화

• Boxcryptor 클라이언트는 사용자의 RSA 비밀 키를 사용하여 암호화된 파일 키를 복호화한다.
• 이 과정은 사용자 디바이스에서 로컬로 수행되며, 비밀 키는 절대로 클라우드로 전송되지 않는다.

2-4. 파일 복호화

• 복호화된 파일 키는 AES 알고리즘을 사용하여 암호화된 파일을 복호화하는 데 사용된다.
• 결과적으로 원래의 파일이 복원된다.

2-5. 파일 반환

• 복호화된 파일은 Boxcryptor 클라이언트를 통해 사용자에게 반환된다.
• 사용자는 원래의 파일에 접근하고 이를 열람하거나 수정할 수 있다.

---

Data Loss Prevention (DLP)

DLP는 클라우드 환경에서 onpremise 환경보다 구현하기가 더 어렵다. 이는 클라우드 고객이 데이터의 입출입 지점(data ingress and egress points)을 직접적으로 통제하기 어렵기 때문이다. 따라서 클라우드 기반 기업 데이터를 보호하기 위해 다양한 DLP 옵션이 필요하다.

1. VPN을 통한 접근 강제
   • 사용자가 기업이 계약한 클라우드 리소스에 접근하기 위해 반드시 가상 사설망(VPN)을 통하도록 강제한다.
   • 이를 통해 데이터 흐름을 중앙에서 통제하고 관리할 수 있다.
2. DLP 에이전트 설치
   • 사용자의 디바이스에 DLP 에이전트를 설치하여 데이터 이동과 사용을 실시간으로 감시한다.
   • 에이전트는 민감 정보의 유출을 방지하는 역할을 한다.
3. IaaS 환경에서 DLP 서버 활용
   • DLP 서버를 사용자 시스템과 클라우드 서버 사이에 프록시로 배치하여 데이터를 모니터링한다.
   • DLP 서버는 모든 트래픽을 분석하며 민감 데이터가 유출되지 않도록 한다.

---

Cloud Application Security

공유 자원(shared resources)에 대한 공격

• 클라우드 컴퓨팅은 자원을 여러 사용자가 공유하는 환경이므로 위협의 양상이 변화한다.
• 보안 취약점이 있는 애플리케이션과 시스템을 공유할 경우, 해당 공유 자원이 손상될 수 있다.
  이로 인해 다른 애플리케이션으로 공격이 확산되는 위험이 존재한다.
• 특히, 사이드 채널 공격(side-channel attack)과 같은 암호화 기반 공격이 공유 리소스 환경을 표적으로 하여 발생할 수 있다.
  예를 들어, CPU 캐시, 네트워크 대역폭, 메모리 접근 패턴을 분석하는 방식으로 공격이 이루어진다.

 

취약한 API(insecure APIs)에 대한 공격

• 클라우드 공급자는 과거에 보안에 문제가 있는 API를 사용한 전례가 있다.
• 최근 5년간 클라우드 보안 사고를 조사한 결과, 약 1/3의 사고가 취약한 API와 인터페이스에서 비롯되었다.
• 별도의 연구에서는 주요 클라우드 서비스 공급자가 사용하는 SSL 라이브러리에 심각한 보안 약점이 있음을 발견하였다.
• 이러한 취약점은 Amazon과 PayPal 같은 주요 클라우드 서비스 제공자에서도 문제가 되었다.이는 API의 잘못된 설계나 보안 강화 미흡이 원인이 될 수 있다.

---

Federated Identity Management (FIdM)

FIdM는 사용자의 인증 정보를 한 시스템에서 관리하고, 이를 여러 독립적인 서비스 제공자 간에 공유할 수 있게 하는 시스템이다. 이 방식은 사용자 편의성과 보안성을 동시에 제공하며, 클라우드와 같은 분산 환경에서 자주 활용된다.

작동 과정 설명

1. Access Request (접근 요청)
   사용자가 제3자 서비스 제공자(Third-Party Service Provider)에 특정 서비스에 접근하려고 요청한다.
   이 요청은 사용자가 원하는 자원에 접근하려는 첫 단계이다.
2. Authentication/Authorization Request (인증/인가 요청)
   서비스 제공자는 사용자의 요청을 처리하기 위해 사용자의 인증 정보가 필요하다.
   따라서 인증 및 인가를 위해 요청을 **Identity Management System(신원 관리 시스템)**으로 전달한다.
3. Authentication Request (인증 요청)
   Identity Management System은 사용자의 신원을 확인하기 위해 인증 요청을 사용자에게 전달한다.
   이는 사용자가 자신의 신원을 증명할 수 있는 자격 증명을 제공해야 함을 의미한다.
4. Authentication Credentials (자격 증명)
   사용자는 자신의 자격 증명을 Identity Management System으로 보낸다.
   이 자격 증명에는 비밀번호, 토큰 또는 기타 인증 방법이 포함될 수 있다.
5. Authorization Response (인가 응답)
   Identity Management System은 사용자의 자격 증명을 검증한 후, 해당 사용자가 요청한 자원에 접근할 수 있는 권한이 있는지 확인한다.
   검증이 완료되면 그 결과를 서비스 제공자에게 전달한다.
6. Access Response (접근 응답)
   제3자 서비스 제공자는 Identity Management System으로부터 받은 결과를 기반으로 사용자가 요청한 자원에 접근할 수 있도록 허용하거나 거부한다.
   최종적으로 사용자는 요청한 서비스에 접근하거나 접근이 거부된다.

특징

• 사용자 편의성: 한 번의 로그인으로 여러 서비스에 접근할 수 있는 SSO(Single Sign-On)와 유사한 구조를 제공한다.
• 보안성: 인증 정보가 한 곳에서 관리되므로 보안이 강화된다.
• 확장성: 다양한 서비스 제공자 간 인증 정보를 공유할 수 있다.

---

Security Assertion Markup Language (SAML)

SAML은 XML 기반 표준으로 시스템 간 사용자 신원 및 권한 정보를 안전하게 교환할 방법을 정의한다. 이는 주로 회사가 직원들에게 클라우드 서비스에 대한 접근 권한을 제공하고자 할 때 사용된다. 회사 직원이 퇴사하면, 해당 사용자의 회사 로그인 정보가 비활성화되고, 이에 따라 클라우드 서비스의 로그인 권한도 자동으로 해제된다.

SAML 인증 과정

SAML 인증은 다음과 같은 과정으로 이루어진다.

1. 사용자가 서비스 제공자(SP)의 사이트에 로그인 요청을 보낸다.
   • 사용자는 브라우저를 통해 SP로 이동하여 인증을 시도한다.
2. 서비스 제공자가 사용자 브라우저로 인증 요청을 보낸다.
   • SP는 사용자 브라우저로 인증 요청을 전달하여 Identity Provider(IdP)로 요청을 중계하도록 한다.
3. 브라우저가 IdP로 인증 요청을 전달한다.
   • 브라우저는 SP에서 전달받은 요청을 IdP로 전달한다.
4. IdP가 사용자 인증을 시도하고, 응답을 생성한다.
   • IdP는 사용자의 신원을 확인한 뒤, 인증 성공/실패 응답을 생성한다.
5. 브라우저가 인증 응답을 SP로 전달한다.
   • 브라우저는 IdP로부터 받은 인증 응답을 SP로 전달한다.
6. SP가 응답을 확인하고 사용자 권한을 적용한다.
   • SP는 인증 응답을 검토하여 사용자가 인증되었는지 확인하고, 해당 사용자를 로그인시키고 권한을 적용한다.

이 과정은 IdP와 SP 간의 신뢰 관계를 기반으로 하며, 사용자의 로그인 정보를 SP와 공유하지 않고 안전하게 인증을 수행할 수 있다.

---

OAuth

OAuth는 인증(authentication)이 아닌 권한 부여(authorization)를 표준화한 기술이다. OAuth는 사용자가 특정 애플리케이션(예: Facebook, Google 등)에서 사용자의 자원을 제3자 애플리케이션에 제공할 수 있도록 하는 방식이다. 이는 사용자 계정의 비밀번호를 공유하지 않고도 특정 자원에 접근할 수 있는 권한을 부여할 수 있다. 사용자는 언제든지 이 권한을 취소할 수 있다.

OAuth 권한 부여 프로세스는 다음과 같다:

1. 리소스 소유자(Resource Owner): 사용자가 클라이언트 애플리케이션 또는 웹사이트에서 자신의 리소스를 사용할 수 있도록 요청을 시작한다.
2. 권한 부여 서버(Authorization Server): 클라이언트가 사용자 리소스에 접근할 수 있는 권한을 요청한다.
3. 리소스 서버(Resource Server): 권한 부여가 성공적으로 이루어지면, 리소스 서버가 해당 요청을 처리하고 리소스를 제공한다.

권한 부여 흐름 개괄적 설명

1. 리소스 소유자가 클라이언트 웹사이트나 애플리케이션에 로그인한다.
2. 클라이언트가 사용자 리소스를 접근하기 위해 권한 부여 서버에 요청을 보낸다.
3. 권한 부여 서버는 사용자 인증을 요청하며, 사용자는 로그인 자격 증명을 입력하여 자신을 인증한다.
4. 인증이 완료되면 권한 부여 서버는 클라이언트에게 인증 코드를 전달한다.
5. 클라이언트는 이 인증 코드를 다시 권한 부여 서버에 제출하여 액세스 토큰을 요청한다.
6. 권한 부여 서버는 인증 코드를 확인한 뒤 클라이언트에게 액세스 토큰을 발급한다.
7. 클라이언트는 발급받은 액세스 토큰을 사용하여 리소스 서버에 요청을 보낸다.
8. 리소스 서버는 토큰을 검증하고 사용자 권한을 확인한 뒤 리소스를 제공하거나 접근을 거부한다.

OAuth는 사용자가 민감한 정보를 직접 제공하지 않아도, 제3자 애플리케이션이 최소한의 필요한 권한으로 리소스를 접근할 수 있도록 허용하는 안전하고 효율적인 방법이다.

---

OpenID Connect (OIDC)

OpenID Connect(OIDC)는 OAuth를 확장하여 인증(authentication)을 지원하기 위한 표준이다. OIDC는 비교적 새로운 연합 ID 관리(FIdM)를 위한 표준이다. 기존의 SAML에 비해 네이티브 애플리케이션(모바일 앱, 데스크톱 애플리케이션 등)에 대한 지원이 훨씬 뛰어나다.OIDC는 기존의 권한 부여 토큰에 ID 토큰을 추가함으로써 작동하며, ID 정보를 또 다른 권한 부여 권리로 취급한다. OIDC는 OAuth와 마찬가지로 사용자 인증 및 권한 관리를 효율적으로 처리하면서도, 추가적인 인증 기능을 통해 현대적인 애플리케이션 요구사항을 충족시킨다.

---

Securing IaaS

 

• Shared Storage(공유 스토리지)
  • 공유 스토리지를 해제하면 해당 스토리지가 다른 사용자에게 재할당될 수 있다. 이는 데이터를 노출시킬 가능성이 있다.
  • 데이터를 보호하기 위해 암호화된 스토리지 볼륨을 사용하는 것이 가장 신뢰할 수 있는 완화 방법이다.
• Shared Network(공유 네트워크)
  • IaaS 공급자는 일반적으로 사용자가 다른 사용자의 네트워크 트래픽을 감지하지 못하도록 설계한다.
  • 하지만, 안전을 보장하려면 가능한 모든 가상 머신과의 네트워크 트래픽을 암호화하는 것이 가장 좋다.
• Host Access(호스트 접근)
  • 이중 인증을 요구해야 한다.
  • 공유 계정을 사용하지 않아야 한다.
  • 최소 권한 원칙을 엄격히 적용해야 한다.
  • 애플리케이션이 API 인터페이스에 접근할 수 있도록 비밀번호 대신 OAuth를 사용하는 것이 바람직하다.
  • 하나의 계정 세트만 관리할 수 있도록 가능한 경우 FIdM을 사용하는 것이 권장된다.

FTP Server와 Web Server를 각각 따로 만들어서 방화벽을 통과하도록 한다. Proxy도 따로 만들어서 통신한다.

---