클라우드 시장(Cloud market) 현황

Study/Technology Issues|2023. 3. 23. 10:01
728x90
반응형

머신러닝, 딥러닝, AI, AI옵스, 빅데이터, IoT, IIOT, 데브옵스, 블록체인, 콜드체인, 옴니채널, 자연어, 데이터 레이크, 인더스트리 4.0등 요즘 우리가 자주 들을 수 있는 이러한 주제의 핵심에는 클라우드가 있다. 이미 알게 모르게 일상의 많은 부분이 클라우드 기술에 의해 움직이고 있고, 기업들 역시 기업 운영을 클라우드 기반으로 점차 전환하고 있는 추세이다 이렇듯 클라우드는 어느새 우리의 생활에 기본적인 요건으로 자리 잡았다.

 

국내 클라우드 시장 동향

클라우드 부분 매출액

 

 

2019년 기준 국내 클라우드 기업의 매출 총액은 3조 원을 넘겼다는 전망이다. 과학기술정보통신부가 지난 9일 공개한 '2019년 클라우드 산업실태조사' 결과에 따르면 지난해 국내 클라우드 기업 예상 매출 총액은 3조 3천549억 원으로 나타났다. 해당 조사는 정보통신산업진흥원이 주관, 1천142개 클라우드 공급 기업을 대상으로 진행됐다.

 

클라우드 산업실태조사는 매년 10월 초에 진행된다. 따라서 당해 매출은 각사에서 예상한 매출로 집계된다. 전년도 매출 총액인 2조 9천707억 원보다 12.9% 가량 증가했을 것으로 예상된다.

 

부문별 매출액을 살펴보면 서비스형 인프라(IaaS)가 1조 5천142억 원, 서비스형 플랫폼(PaaS)이 1천999억 원, 서비스형 소프트웨어(SaaS)가 1조 999억 원을 기록했을 것으로 집계됐다.

 

클라우드 서비스 브로커(CSB)와 클라우드 관리 서비스(CMS)는 2천815억 원, 클라우드 보안 서비스(SECaaS)는 2천115억 원으로 나타났다.

 

클라우드 기업 중 수출을 하는 기업은 4.7% 수준이었다. 수출 중인 기업의 국내외 법인 수출액 총액은 83억700만 원으로, 전년도 256만 달러(약 29억 6천만 원)에 비해 증가했다.

 

대표사진 삭제

클라우드 부문별 19년도 예상 매출액 합(출처: 2019 클라우드 산업 실태 조사)

 

클라우드 기업들은 해외 진출 고려 지역에 대해 동남아시아가 36.8%로 가장 많이 언급했다. 그 외 일본(29.8%), 중국(28.1%), 북아메리카(24.6%)도 높은 응답률을 기록했다.

 

업계는 국내 클라우드 산업 활성화 저해 요인으로는 보안(29.7%)이 지난해에 이어 1위를 차지했다. 도입 비용의 부담(29.3%), 성능의 불확실성(14.7%), 관리자 인식 부족(10.3%) 등이 그 뒤를 이었다.

 

클라우드 사업 수행 시 겪는 애로사항 1순위로는 시장정보 부족이 19.8%로 가장 높은 응답률을 보였다. 이후 경기침체(17.2%), 과다경쟁(17.1%), 마케팅 전문인력 부족(15.0%) 등의 순으로 응답률이 높게 나타났다.

 

업계는 국내 클라우드 산업 활성화를 위한 정부 차원의 필요 정책 1순위로 기술개발·도입 자금 지원(37.8%)을 가장 많이 꼽았다. 그 외 마케팅·영업 등 지원(17.4%), 법·제도 개선(9.8%), 공공 부문 클라우드 도입 활성화(8.6%) 등의 순으로 응답률이 높게 나타났다.

 

클라우드 산업 발전 및 경쟁력 강화를 위해 국내에서 가장 시급히 개발돼야 하는 기술로는 보안기술이 48.3%로 가장 많은 응답 비중을 차지했다. 다음으로 분산 데이터 저장 기술 (17.1%), 관리 자동화 기술(13.3%), 시스템 제어 기술(8.8%) 등의 순이었다.

 

 

국외 클라우드 시장 동향

 

빠르게 변화하는 비즈니스 환경에 의해 현재는 NIST의 정의에 대해 논쟁의 소지가 있을 수 있다. 불과 몇 년 전만 해도 많은 글로벌 TOP IT 기업들의 기조연설에는 여러 신생 기업들이 기존 다국적 기업들의 비즈니스 환경을 바꾼 사례가 자주 등장한다. AirBnB와 Global Hotel Chain, Uber와 Taxi Industry, WeWork와 Global Reality의 사례가 대표적이다. 하지만 이것 또한 최근 코로나 19(Covid-19)의 여파로 다음의 패러다임으로 빠르게 변화하고 있다. 여러 분야의 각 기업들은 빠르게 변화하고 있는 비즈니스 과도기에 상당히 많은 부분을 클라우드에 투자하고 있다.

 

 
사진 삭제

전 세계 IT 지출 전망(자료: 가트너, 2020.01)

 

이 시점에서 최근 Fortune 500대 글로벌 기업들의 클라우드 전략을 살펴볼 필요가 있다. 이들은 클라우드 도입 초반에는 플랫폼의 중요성만을 강조하며 대부분 기존 IT 기반을 클라우드 플랫폼으로 단일화했다. 이로 인해 경영의 효율성은 높아졌지만 단점들도 눈에 띄었다. 전반적인 운영 방향은 클라우드이지만 비즈니스 환경은 빠르게 변화하고 있다.

 

혁신이라는 측면에서 다양한 Best of Breed 형태의 클라우드가 나타나고 있고, 클라우드 스택(Cloud Stack)의 기본인 IaaS(Infrastructure As A Service)는 이미 대중화되어 AWS, MS Azure, GCP 위주로 시장이 형성되어 있다. 최첨단 기술에 민감한 글로벌 TOP 기업들은 이미 기존의 단일 클라우드 환경에서 멀티 클라우드와 하이브리드 클라우드로 넘어가고 있다.

 

표준화된 IaaS 영역의 클라우드 단일화에서 탈피해 특정 SaaS 영역의 Best of Breed SaaS 솔루션에 따라 최적화된 특정 PaaS & IaaS 영역으로 전반적인 클라우드 환경을 바꾸고 있다. 예를 들어 구글의 경우 BigQuery, 이미 구글이 확보한 이메일/유튜브 사용자 등을 바탕으로 한 특정 마케팅 솔루션과 analytic을 활용하는 데에는 다른 IaaS보다 GCP가 더 유리하다는 점을 무시할 수 없다.

 

멀티 클라우드는 특정 목적과 솔루션에 맞춰 클라우드 기반을 다양하게 가져가는 전략이고, 하이브리드 클라우드는 특정 목적에 맞게끔 퍼블릭 클라우드와 프라이빗 클라우드를 적절히 조합한 환경이며, 더 나아가서는 특정 상황에서 적절한 온프레미스를 조합해 더 효율적인 환경을 구성할 수 있다.

 

 
 
SEcaaS(Security as a Service) 포트폴리오

 

향후의 클라우드 트렌드는 다양하고 빠르게 변화하는 하이브리드 멀티 클라우드 환경을 통합 지원하는 SEcaaS(Security as a Service)와 멀티 환경으로 인해 생기는 네트워크 레이턴시를 해결하는 클라우드 피어링(Peering) 그리고 다양한 클라우드/온프레미스를 효율성 있게 구축(Multi Cloud DevOpsl AlOps)하고 운영(Business Continuity)하여 고도화하는 Managed Service가 주역이 될 것이다.

 

본 자료는 2020년 11월에 개인(투투아빠)적으로 분석하기 위해 작성한 자료로 최신 자료를 살펴볼 필요가 있습니다.

 

 

728x90
반응형

'Study > Technology Issues' 카테고리의 다른 글

CSA(Cloud Security Alliance) Publication 이란?  (0) 2023.03.23
Web 3.0 IPFS 분산파일 시스템  (0) 2023.03.17
Web 3.0 기술 중 IPFS 기술에 대해  (0) 2023.03.17
ChatGPT 아시나요?  (0) 2022.12.12
qmil 설치방법  (0) 2019.09.03

댓글()

CSA(Cloud Security Alliance) Publication 이란?

Study/Technology Issues|2023. 3. 23. 09:59
728x90
반응형

CSA(Cloud Security Alliance)는 “클라우드 컴퓨팅 내에서 보안 보증을 제공하는 모범 사례사용을 촉진하고 기타 모든 형태의 컴퓨팅을 보호할 수 있도록 클라우드 컴퓨팅 사용에 대한 교육을 제공”하는 비영리 조직이다. 국내에는 클라우드 컴퓨팅 환경으로 변모 중인 국내 IT 산업 환경에 대비하여, 안전한 미래 사업 환경을 조성하고, 수익을 창출하기 위하여 (사)한국클라우드보안협회가 2008년 말에 설립되었다.

 

CSA에서 ‘17년에 발간한 ’For Critical Areas of Focus In Cloud Computing v4.0’에 대해서 간략하게 알아보며, 발간물을 통해 클라우드 컴퓨팅에 대한 기본 정의에 대해 알아본다.

 

1 클라우드 컴퓨팅 개념과 아키텍처(Cloud Computing Concepts and Architectures)

출처 입력

이 도메인은 Cloud Security Alliance의 지침에 대한 개념적 프레임워크를 제공한다. 클라우드 컴퓨팅에 대한 정의, 기본 용어에 대한 설명, 전체적인 논리적 아키텍처 프레임워크를 설명한다.

 

해당 도메인은 아래의 4가지 항목을 포함하고 있다.

 

▶ 클라우드 컴퓨팅 정의

▶ 클라우드 논리 모델

▶ 클라우드 개념, 아키텍처 및 참조 모델

▶ 클라우드 보안 및 규정 준수 범위, 책임 및 모델

 

CSA는 완전히 새로운 분류체계나 참조 모델을 만들려고 하는 것은 아니며, 목표는 기존 모델(NIST Special Publication 800-145, ISO/IEC 17788 및 ISO/IEC 17789)을 보안과 관련이 높은 항목들에 대해 초점을 맞춘 것이다.

 

1.1 클라우드 컴퓨팅 정의

 

클라우드 컴퓨팅은 컴퓨팅 리소스의 공유 풀을 관리하기 위한 새로운 운영 모델이자 기술 셋이다.

 

NIST에서는 다음과 같이 정의하였다.

▶ 클라우드 컴퓨팅은 구성 가능한 컴퓨팅 리소스(예: 네트워크, 서버, 스토리지, 애플리케이션 및 서비스)의 공유 풀에 대한 유비쿼터스의 편리한 온-디맨드(On-demand: 공급중심이 아닌 수요 중심에서 결정하는 시스템이나 전략등을 총칭함) 네트워크 액세스가 가능한 모델이다.

 

ISO/IEC에서는 매우 간단하게 정의를 하였다.

▶ 셀프서비스 프로비저닝 및 온 디멘드(On-demand) 관리를 통해 공유 가능한 물리적 또는 가상 리소스의 확장이 가능하고 탄력적 풀에 대한 네트워크 액세스를 가능하게 하는 패러다임

 

더 간단히 클라우드를 설명하는 방법은 프로세서와 메모리와 같은 리소스 집합을 가져와서 큰 풀에 넣는 것이다. 소비자는 8개의 CPU와 16GB의 메모리와 같은 풀에서 필요한 것을 요청하고, 클라우드는 이러한 리소스를 클라이언트에 할당 한 다음 네트워크를 통해 연결하여 사용하는 것이다. 클라이언트가 완료되면 다른 사람이 사용할 수 있도록 리소스를 다시 해제할 수 있다.

 

클라이언트 사용자는 리소스를 요청하고 사용하는 사람 또는 조직이고, 클라우드 공급자는 리소스를 제공하는 사람 또는 조직이다. 또한, 때때로 클라우드 사용자 및 서비스를 지칭하기 위해 클라이언트 및 소비자라는 용어를 사용하기도 한다. NIST 500-292는 “클라우드 행위자”라는 용어를 사용하며, ISO/IEC 17788은 클라우드 서비스 고객, 클라우드 서비스 파트너 및 클라우드 서비스 공급자라는 용어를 사용한다.

 

1.2 모델 정의

 

CSA는 클라우드 컴퓨팅 모델을 정의하기 위한 표준으로 NIST 모델을 사용한다. 또한 추가로 ISO/IEC 모델을 참조한다.

NIST는 5가지 필수 특성, 3가지 클라우드 서비스 모델 및 4가지 클라우드 배포 모델을 설명하여 클라우드 컴퓨팅을 정의한다.

 

 
사진 삭제

클라우드 컴퓨팅 모델

 

 

1.2.1 필수 특성(Essential Characteristics)

 

필수 특성은 클라우드를 만드는 특성이다. 위 그림에서 Essential Characteristics 범주의 특성에 포함이 된다면 클라우드 컴퓨팅으로 간주한다. 하지만 특성 중 하나라도 포함되지 않는다면 클라우드의 특성이 아닐 확률이 높다.

 

▶ 리소스 풀링(Resource Pooling)은 가장 기본적인 특성이다. 공급자는 리소스를 추상화하고 Pool로 수집할 수 있으며, 일부는 다른 소비자에게 할당 할 수 있다.

▶ 소비자는 주문형 셀프서비스(On-Demand Self-Service)를 사용하여 Pool에서 리소스를 프로비저닝 한다. 관리자와 상의할 필요 없이 리소스를 직접 관리한다.

▶ 광범위한 네트워크 액세스는(Borad Network Access) 직접적인 물리적 액세스 없이 네트워크를 통해 모든 리소스를 사용할 수 있어야만 한다. 하지만 네트워크는 서비스의 일부에서 제외된다.

▶ 빠른 탄력성(Rapid Elasticity) 덕분에 소비자는 풀에서 사용하는 리소스를 확장하거나 축소할 수 있다.(프로비저닝 및 디프로비저닝) 이를 통해 리소스 소비와 수요를 보다 밀접하게 일치시킬 수 있다.(수요가 증가하면 가상서버를 추가하고 수요 감소 시에는 드랍시킴)

▶ 측정된 서비스(Measured Service)는 제공되는 항목을 측정하여 소비자가 할당 된 항목만 사용하고 필요한 경우 요금을 부과하도록 한다. 이것으로 인해 유틸리티 컴퓨팅이라는 용어가 나오게 되었다.

▶ ISO/IEC 17788에는 6가지 주요 특성이 나열되어 있다. 그 중 5개는 NIST 특성과 같다. 유일한 추가는 리소스 풀링과는 다른 멀티테넌시이다.

 

1.2.2 서비스 모델(Service Models)

 

NIST는 클라우드 서비스의 다양한 기본 범주를 설명하는 3가지 서비스 모델의 정의한다.

 

▶ SaaS(Software as a Service)는 공급자가 관리하고 호스팅하는 완전한 애플리케이션이다. 소비자는 웹 브라우저, 모바일 앱 또는 경량 클라이언 앱을 통해 액세스 한다.

▶ PaaS(Platform as a Service)는 데이터베이스, 애플리케이션 플랫폼(ex. Python, PHP 또는 기타 코드 실행 장소) 파일 저장 및 공동 작업 또는 독점 애플리케이션 처리(예: 기계학습, 빅데이터 처리 또는 SaaS 애플리케이션 기능에 대한 직접적인 API(응용 프로그래밍 인터페이스) 액세스)와 같은 플랫폼을 추상화하고 제공한다.

▶ IaaS(Infrastructure as a Service)는 컴퓨팅, 네트워크 또는 스토리지와 같은 기본 컴퓨팅 인프라의 리소스 풀에 대한 액세스를 제공한다.

 

해당 계층은 때때로 “SPI”라고 불린다. ISO/IEC는 SPI 계층(애플리케이션, 인프라 및 플랫폼 기능 유형)에 밀접하게 맵핑되는 클라우드 기능 유형으로 복잡한 정의를 사용한다. 그런 다음 Compute as a Service, Data Storage as a Service와 같이 보다 세분화된 클라우드 서비스 범주로 확장된 다음 IaaS, PaaS, SaaS를 포함하게 된다.

 

1.2.3 배포 모델

 

NIST와 ISO/IEC는 모두 동일한 4개의 클라우드 배포 모델을 사용한다.

 

▶ Public Cloud: 클라우드 인프라는 일반 대중이나 대규모 산업 그룹이 사용할 수 있으며, 클라우드 서비스를 판매하는 조직을 소유한다.

▶ Private Cloud: 클라우드 인프라는 단일 조직을 위해서만 운영된다. 조직 또는 제삼자가 관리할 수 있고, 온 프레미스(On-premise: 소프트웨어 등 솔루션을 클라우드 같이 원격 환경ㅇ이 아닌 자체적으로 보유한 서버에 직접 설치에 운영하는 방식) 또는 오프 프레미스(Off-Premises: 온프레미스와 반대로 클라우드 방식의 서비스를 의미)에 위치할 수 있다.

▶ Community Cloud: 클라우드 인프라는 여러 조직에서 공유하며, 보안 요구사항, 정책 또는 규정 준수 고려사항 등을 공유한 특정 커뮤니티를 지원한다. 조직 또는 제삼자가 관리할 수 있으며, 온 프레미스 또는 오프 프레미스에 위치할 수 있다.

▶ Hybrid Cloud: 클라우드 인프라는 고유한 엔티티로 유지되지만 데이터 및 애플리케이션 이식성을 가능하게 하는 표준화 또는 독점 기술(ex. 클라우드 간 로드 밸런싱을 위한 클라우드 버스팅)에 의해 결합하는 둘 이상의 클라우드(사설, 커뮤니티 또는 공용)로 구성된다. 하이브리드는 일반적으로 클라우드 제공업체에 직접 연결된 비 클라우드 에이터 센터를 설명하는데 사용된다.

 
사진 삭제

클라우드 배포 모델 및 인프라(자료: IssA M Khali et al. 2014.02)

 

1.3 참조 및 아키텍처 모델

 

최근에는 클라우드 서비스를 구축하기 위해 끊임없이 진화하는 기술 기법이 광범위하여 처음부터 단일 참조 모델이나 아키텍처 모델을 쓸모없게 만들고 있다. 해당 부분의 목적은 보안 전문가들이 정보를 제공하는 데 도움이 되는 몇 가지 기본사항과 새로운 모델을 이해하기 위한 기준을 제공하는 것이다.

 

 
사진 삭제

사진 설명을 입력하세요.

 

1.3.1 IaaS(Infrastructure as a Service)

 

물리적 시설 및 인프라 하드웨어는 IaaS의 기반을 형성한다. 클라우드 컴퓨팅을 통해 이러한 리소스를 추상화하고 풀링하지만 가장 기본적인 수준에서는 구축할 물리적 하드웨어, 네트워크 및 스토리지가 필요하다. 이러한 리소스는 추상화 및 오케스트레이션을 사용하여 풀링된다. 추상화는 가상화를 통해 리소스를 물리적 제약에서 해제하여 풀링을 가능하게 하고, 핵심 연결 및 전달 도구(오케스트레이션: 컴퓨터 시스템과 어플리케이션 서비스의 자동화된 설정, 관리, 조정을 의미)가 이러한 추상화된 리소스를 함께 연결하고 풀을 생성하여 자동으로 고객에게 제공한다.

 

이 모든 것은 응용 프로그래밍 인터페이스를 사용하여 촉진된다. API는 일반적으로 클라우드 내의 구성 요소에 대한 기본 통신 방법이며, 일부(또는 완전히 다른 집합)는 클라우드 사용자에게 노출되어 리소스 및 구성을 관리한다. 요즘 대부분의 클라우드 API는 HTTP 프로토콜을 통해 실행되는 REST(Representational State Transfer)를 사용하므로 인터넷 서비스에 매우 적합하다.

 

대부분의 경우 이러한 API는 원격으로 액세스 할 수 있으며, 웹 기반 사용자 인터페이스로 랩핑된다. 소비자가 가상머신(인스턴스) 시작 또는 가상 네트워크 구성과 같은 클라우드 리소스를 관리 및 구성하는데 사용하기 때문에 이 조합은 클라우드 관리영역이다. 보안 관점에서 볼 때 물리적 인프라 보호와의 가장 큰 차이점(물리적 액세스를 제어 수단으로 사용할 수 없기 때문에)이자 클라우드 보안 프로그램을 설계 할 때 최우선 순위이다. 공격자가 관리영역에 침입하면 잠재적으로 전체 클라우드 배포에 대한 완전한 원격 액세스 권한을 갖게 된다.

 

따라서, IaaS는 시설, 하드웨어, 추상화 계층, 추상화 된 리소스를 함께 연결하는 오케스트레이션(핵심 연결 및 전달) 계층과 리소스를 원격으로 관리하고 소비자에게 제공하는 API로 구성된다.

 

 
사진 삭제

컴퓨팅 IaaS 플랫폼의 단순화 된 아키텍처

 

위의 그림은 오케스트레이션을 위한 컴퓨팅 및 스토리지 컨트롤러, 추상화를 위한 하이퍼 바이저, 컴퓨팅과 스토리지 풀 간의 관계를 보여주는 간단한 다이어그램이다. 하지만 네트워크 관리자와 같은 많은 구성 요소가 생략되어 있다.

 

일련의 물리적 서버는 각각 하이퍼 바이저(가상화 용)와 서버를 연결하고 컴퓨팅 컨트롤러에 연결하는 관리/오케스트레이션 소프트웨어의 두 가지 구성 요소를 실행한다. 고객이 특정 크기의 인스턴스(가상서버)를 요청하면 클라우드 컨트롤러가 용량이 있는 서버를 결정하고 요청된 크기의 인스턴스를 할당한다. 그런 다음 컨트롤러는 스토리지 컨트롤러에서 스토리지를 요청하여 가상 하드디스크 드라이브를 생성하여 스토리지 풀에서 스토리지를 할당하고 이를 네트워크(스토리지 트래픽 전용 네트워크)를 통해 적절한 호스트 서버 및 인스턴스에 연결한다. 가상 네트워크 인터페이스 및 주소를 포함한 네트워킹도 필요한 가상 네트워크에 할당되고 연결된다. 그런 다음 컨트롤러는 서버 이미지의 사본을 가상 머신으로 전송하고 부팅한 다음 구성을 완료한다. 이렇게 하면 가상 네트워킹 및 스토리지가 모두 올바르게 구성된 가상머신(VM)에서 실행되는 인스턴스가 생성된다. 이 전체 프로세스가 완료되면 메타 데이터 및 연결 정보가 클라우드 컨트롤러에 의해 중개되고 소비자가 사용할 수 있으며, 소비자는 이제 인스턴스에 연결하고 로그인 할 수 있다.

 

1.3.2 PaaS(Platform as a Service)

 

모든 서비스 모델 중에서 PaaS는 광범위한 PaaS 오퍼링과 PaaS 서비스를 구축하는 다양한 방법으로 특성화하기 가장 어렵다. PaaS는 애플리케이션 개발 프레임 워크, 미들웨어 기능 및 데이터베이스, 메시징 및 대기열과 같은 기능과의 추가 통합계층을 추가한다. 이러한 서비스를 통해 개발자는 스택에서 지원하는 프로그래밍 언어 및 도구를 사용하여 플랫폼에서 애플리케이션을 빌드 할 수 있다.

 

현실 세계에서 자주 볼 수 있는 모델 옵션 중 하나는 IaaS 위에 플랫폼을 구축하는 것이다. 통합 및 미들웨어 계층은 IaaS에 구축 된 다음 함께 풀링되고 조정되며 PaaS로 API를 사용하여 고객에게 노출된다. 예를 들어 Database as a Service는 IaaS에서 실행되는 인스턴스에 수정 된 데이터베이스 관리 시스템 소프트웨어를 배포하여 구축할 수 있다. 고객은 API(및 웹 콘솔)를 통해 데이터베이스를 관리하고 일반 데이터베이스 네트워크 프로토콜을 통해 API를 액세스 한다.

 

 
사진 삭제

IaaS 아키텍처 기반 PaaS 애플리케이션 플랫폼 아키텍처

 

 

PaaS는 반드시 IaaS 기반에 구축될 필요는 없다. PaaS가 맞춤 독립형 아키텍처가 될 수 있지만 정의하기 어려운 이유는 소비자 접근과 플랫폼 관리가 근본적으로 인프라 기반이기 때문이다.

 

1.3.3 SaaS(Software as a Service)

 

SaaS 서비스는 대규모 소프트웨어 플랫폼의 모든 아키텍처 복잡성을 가진 완전한 다중 테넌트 애플리케이션이다.

 

대부분의 최신 클라우드 애플리케이션(SaaS 또는 기타)은 IaaS와 PaaS의 조합을 사용하며, 때로는 다른 클라우드 제공 업체 간에 사용되기도 한다. 또한 많은 사람들이 일부 기능에 대해 공용 API를 제공하는 경향도 있다. 다양한 클라이언트, 특히 웹 브라우저 및 모바일 애플리케이션을 지원하기 위해 이런 기능들이 필요로 한다. 따라서 모든 SaaS에는 애플리케이션/로직 레이어 및 데이터 스토리지가 있으며, API가 맨 위에 존재한다.

 

 

 
사진 삭제

SaaS 플랫폼 구성도

 

1.4 로직 모델

 

높은 수준에서 클라우드와 기존 컴퓨팅 모두 기능에 따라 다른 계층을 식별하는데 도움이 되는 논리적 모델을 준수한다. 이는 서로 다른 컴퓨팅 모델 자체의 차이점을 설명하는데 유용하다.

 

▶ 인프라(Infrastructure): 컴퓨팅 시스템의 핵심 구성 요소 – 컴퓨팅, 네트워크 및 스토리지

▶ 메타구조(Metastructure): 인프라 계층과 다른 계층 간의 인터페이스를 제공하는 프로토콜 및 메커니즘. 기술을 연결하고 관리 및 구성을 가능하게 하는 접착제 역할

▶ 정보구조(Infostructure): 데이터 및 정보, 데이터베이스, 파일 저장소 등의 콘텐츠

▶ 애플리케이션 구조(Applistructure): 클라우드에 배포된 애플리케이션과 이를 구축하는데 사용되는 기본 애플리케이션 서비스(메시지 대기열, 인공지능 분석 또는 알림 서비스와 같은 PaaS 기능)

 

클라우드와 기존 컴퓨팅의 주요 차이점은 메타 구조이다. 클라우드 메타 구조에는 네트워크를 지원하고 원격으로 액세스 할 수 있는 관리영역 구성 요소가 포함되어 있다. 또 다른 차이점은 클라우드에서는 각 레이어에 이중화하는 경향이 있다는 것이다. 예를 들어 인프라에는 클라우드 생성에 사용되는 인프라뿐만 아니라 클라우드 사용자가 사용하고 관리하는 가상 인프라가 모두 포함된다는 점이다. 공공 클라우드에서는 제공자가 물리적 인프라를 관리하는 반면, 소비자가 가상 인프라의 일부를 관리하지만 사설 클라우드에서는 동일한 조직이 두 가지 모두 관리가 가능해야 한다.

 

1.5 클라우드 보안 범위, 책임과 모델

 

1.5.1 클라우드 보안과 규정 준수 범위 및 책임

 

클라우드 보안 및 규정 준수에는 보안 팀이 클라우드 영역 내에 담당하는 모든 부분이 포함된다. 전통적인 보안 영역은 그대로 유지되지만 위험, 역할 및 책임의 특성은 종종 변화하기도 한다.

 

보안과 규정 준수의 전체 범위는 변하지 않지만, 주어진 클라우드 운영자가 책임져야 할 부분은 거의 확실하다. 이것은 일반적으로 공동 책임 모델이라고 한다. 특정 클라우드 제공업체 및 기능/제품, 서비스 모델 및 배포 모델에 따라 달라지는 책임 매트릭스로 생각하면 된다.

 

 
사진 삭제

아키텍처 스택에 따른 보안 책임

 

행위자가 아키텍처 스택에 대해 규제 수준에 따라 보안 책임 범주가 다르게 된다. 가장 중요한 보안 고려 사항은 주어진 클라우드 프로젝트에서 누가 무엇을 책임지고 있는지 정확하게 판단하고 있어야 하는 것이다. 특히 클라우드 업체가 제공하는 클라우드의 기능과 작동 방식을 정확히 알고 있어야 하는 것이다.

 

▶ SaaS(Software as a Service): 클라우드 사용자는 애플리케이션 사용에 액세스 및 관리만 할 수 있고, 애플리케이션 작동 방식을 변경할 수는 없기 때문에 클라우드 제공업체에서 대부분의 보안을 담당한다. 예를 들어 SaaS 공급자는 경계 보안, 로깅/모니터링/감사 및 애플리케이션 보안을 담당하는 반면 소비자는 권한 부여 및 권한만 관리한다.

▶ PaaS(Platform as a Service): 클라우드 공급자는 플랫폼의 보안을 책임지고, 소비자는 제공된 보안 기능을 구성하는 방법을 포함하여 플랫폼에서 구현하는 모든 것에 대한 책임을 진다. 따라서 책임이 균등하게 분할된다. 예를 들어 Database as a Service를 사용하는 경우 공급자는 기본 보안, 패치 및 핵심 구성을 관리하고 클라우드 사용자는 사용할 데이터베이스의 보안 기능, 계정 관리 또는 인증 방법을 포함한 다른 모든 것을 책임진다.

▶ IaaS(Infrastructure as a Service): PaaS와 마찬가지로 제공업체는 기본 보안을 담당하고 클라우드 사용자는 인프라에 구축된 모든 것을 담당한다. PaaS와 달리 IaaS는 클라이언트에게 더 많은 책임을 부여한다. 예를 들어 IaaS 공급자는 공격에 대한 경계를 모니터링해야 할 수 있으며, 소비자는 서비스에 사용할 수 있는 도구를 기반으로 가상 네트워크 보안을 정의/구현하는 방법에 대해 전적으로 책임을 진다.

 

CSA는 이러한 요구사항을 충족하는 데 도움이 되는 두 가지 도구를 제공한다

 

▶ CAIQ(Consensus Assessments Initiative Questionnaire): 클라우드 공급자가 보안 및 규정 준수 규제를 문서화하기 위한 표준 템플릿

▶ CCM(The Cloud Controls Matrix): 클라우드 고객이 클라우드 제공업체에 대한 전반적인 보안 위험을 평가하는데 도움을 주기 위한 기본 보안원칙을 제공하도록 설계된 가이드라인. CCM을 사용하여 보안 책임을 문서화할 수도 있음

 

1.5.2 클라우드 보안 모델

 

클라우드 보안 모델은 보안 의사결정을 안내하는데 도움이 되는 도구이다. “모델”이라는 용어는 다소 불규칙적으로 사용될 수 있으므로, 다음과 같이 유형을 구분한다.

 

 개념적 모델 또는 프레임워크에는 CSA 논리 모델과 같은 클라우드 보안 개념 및 원칙을 설명하는 데 사용되는 시각화 및 설명을 포함한다.

 규제 모델 또는 프레임워크는 특정 클라우드 보안 규제 또는 규제 범위(예: CSA CCM)를 분류하고 설명한다.

 참조 아키텍처는 일반적으로 일반화된 클라우드 보안을 구현하기 위한 템플릿(예: IaaS 보안 참조 아키텍처)이다. 해당 아키텍처는 매우 추상적일 수 있고, 개념에 가까울 수 있으며, 상세하게 설명될 수 있다. 또한 특정한 통제나 기능에 해당 될 수 있다.

 디자인 패턴은 특정 문제에 대한 재사용이 가능한 해결책이다. 예로는 IaaS 로그 관리가 있다. 참조 아키텍처와 마찬가지로 특정 클라우드 플랫폼의 일반적인 구현 패턴에 이르기까지 다소 추상적이거나 구체적일 수 있다.

 

이러한 모델 사이의 경계는 모델 개발자의 목표에 따라 종종 겹치기도 한다. “모델”이라는 제목 아래에 이 모든 것을 하나의 그룹으로 두는 것조차 정확하지 않을 수 있지만 용어가 서로 다른 소스에서 서로 바뀌어 사용되는 것을 볼 수 있으므로 그룹화하는 것이 좋다.

 

CSA는 다음 모델을 검토하고 권고하였다.

 

 The CSA Enterprise Architecture

 The CSA Cloud Controls Matrix

 The NIST draft Cloud Computing Security Reference Architecture (NIST Special Publication 500-299), which includes conceptual models, reference architectures, and a controls framework.

 ISO/IEC FDIS 27017 Information technology – Security techniques – Code of practice for information security controls based on ISO/IEC 27002 for cloud services.

 

2 거버넌스 및 엔터프라이즈 위험 관리(Governance and Enterprise Risk Management)

 

거버넌스 및 위험 관리는 매우 광범위한 주제이다. 해당 지침은 클라우드 컴퓨팅에서 어떻게 변화하는지에 중점을 둔다. 보안 전문가에게 클라우드 컴퓨팅은 거버넌스 및 위험 관리의 4가지 영역에 영향을 준다.

 

첫 번째: 거버넌스는 조직 운영방식을 구성하는 정책, 프로세스 및 내부 관리사항 등을 포함한다. 구조 및 정책에서 리더십 및 기타 관리 메커니즘에 이르기까지 다양한 사항들이 있다.

 

거버넌스에 대한 자세한 내용은 아래의 내용을 참조한다.

 

 ISO/IEC 38500:2015 - Information Technology - Governance of IT for the organization

 ISACA - COBIT - A Business Framework for the Governance and Management of Enterprise IT

 ISO/IEC 27014:2013 - Information Technology - Security techniques - Governance of information security

 

두 번째: 엔터프라이즈 위험 관리에는 조직의 거버넌스 및 위험 허용 범위에 맞춰 조직의 전반적인 위험 관리가 포함된다. 엔터프라이즈 위험 관리에는 기술과 관련된 영역뿐만 아니라 모든 위험 영역이 포함된다.

 

위험 관리에 대한 자세한 내용은 아래의 내용을 참조한다.

 

 ISO 31000:2009 - Risk management – Principles and guidelines

 ISO/IEC 31010:2009 - Risk management – Risk assessment techniques

 [NIST Special Publication 800-37 Revision 1](updated June 5, 2014) (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r1.pdf)

 

세 번째: 정보 위험 관리에는 정보 기술을 포함한 정보 위험 관리에 관한 것이다. 조직은 금융에서 물리적까지 모든 종류의 위험에 직면하고 있으며, 정보는 조직이 관리해야 할 여러 자산 중 하나에 불과하다.

 

네 번째: 정보 보안은 정보에 대한 위험을 관리하는 도구와 실천사항들이다. 정보 보안은 위험 정보의 관리가 전부가 아니다. 정책, 계약, 보험 및 기타 메커니즘의 역할도 한다. 그러나 정보 보안의 주된 역할은 전자정보와 이를 액세스 하는데 사용하는 시스템을 보호하기 위한 프로세스 및 규제를 제공하는 것이다.

 

위험 관리는 선택한 클라우드 구축 및 서비스 모델을 기반으로 보안 및 위험 관리에 대한 공유 및 책임 등을 파악해야 한다. 관련 업계 모범사례, 글로벌 표준 및 CSA CCM, COBIT 5, NIST RMF, ISO/IEC 27017, HIPAA, PCI DSS, EU GDPR 등과 같은 규정에 따라 클라우드 거버넌스 프레임워크 및 모델을 개발해야 한다.

 

3 법적 문제, 계약 및 전자적 증거 수집(Legal Issues, Contracts and Electronic Discovery)

 

해당 파트는 데이터를 클라우드로 이동함으로써 제기 된 몇 가지 법적 문제를 다루고 있다. 클라우드 서비스 제공업체와 계약 소송에서 전자적 검색 요청을 처리한다. 하지만 해당 개요는 잠재적인 모든 법적 상황들을 다룰 수는 없다. 특정 문제를 해결하기 위해서는 운영하려는 담당자 및 고객이 거주하는 지역의 법률 고문과 상의해야 한다. 또한 법률 및 규정은 자주 변경되므로 해당 파트에 포함된 정보의 관련성을 확인해야 한다.

 

해당 파트는 주로 퍼블릭 클라우드 컴퓨팅 및 타사 호스팅 개인 클라우드의 법적 의미에 대한 내용을 담고 있다. 해당 파트는 데이터 거버넌스 및 감사/준수사항에 대한 몇 가지 측면이 포함되어 있지만 이러한 주제는 다음 2.4와 2.5에서 자세히 다루게 되어 있다.

 

해당 파트가 다루는 영역은 다음과 같다.

 

 법적인 문제

 클라우드 서비스 계약

 클라우드에 저장된 전자 문서에 대한 제 3자 액세스

 

4 규정 준수 및 감사 관리(Compliance and Audit Management)

 

조직들은 기존 데이터센터에서 클라우드로 마이그레이션하면서 새로운 과제에 직면해 있다. 여러 국가에 걸쳐 다수의 규제 준수를 제공, 측정 및 전달하는 것은 이러한 과제 중 가장 큰 문제 중 하나이다. 고객과 공급자는 기존 준수사항 및 감사 표준, 프로세스, 사례들에 대한 차이들을 이해하고 평가할 필요가 있으며, 클라우드 컴퓨팅의 분산 및 가상화 특성은 정보와 프로세스의 물리적 인스턴스화를 기반으로 접근방식에 대한 조정이 필요하다.

 

공급자와 고객 외에도 규제 기관과 감사 인원도 클라우드 컴퓨팅의 새로운 세계에 적응하고 있다. 가상화 환경이나 클라우드 구현을 고려하는 기존 규정은 거의 없었다. 클라우드 사용자는 감사인에게 조직이 규정을 준수하고 있음을 보여주어야 한다. 클라우드 컴퓨팅과 규제 환경의 상호 작용을 이해하는 것은 모든 클라우드 전략의 핵심 구성 요소이다. 클라우드 고객, 감사자 및 공급자는 다음 사항을 고려해야 한다.

 

 특정 클라우드 서비스 또는 제공업체 사용에 대한 규제적 영향(해당하는 경우 국경을 초월한 문제 또는 여러 주제의 문제에 특히 주의를 기울임)

 간접 제공자(즉, 클라우드 공급자의 클라우드 공급자)를 포함하여 공급자와 고객 간의 규정 준수 책임을 할당.

 문서 및 증거 생산, 프로세스 준수를 포함하여 적시에 입증할 수 있는 공급자 기능

 

특히 주의해야 할 몇 가지 추가 클라우드 관련 문제는 다음과 같다.

 

 공급자 감사 및 인증의 역할과 인증이 고객 감사 범위에 미치는 영향

 감사 및 평가 범위 내에 있는 클라우드 공급자의 기능 및 서비스 이해

 시간 경과에 따른 규정 준수 및 감사 관리

 클라우드 컴퓨팅 기술에 대한 경험이 부족할 수 있는 규제 기관 및 감사자와의 협력

 감사 및 규정 준수 경험이 부족할 수 있는 공급자와의 협력

 

5 정보 거버넌스(Information governance)

 

정보 보안의 주요 목표는 시스템 및 애플리케이션을 구동하는 기본 데이터를 보호하는 것이다. 기업이 클라우드 컴퓨팅으로 전환함에 따라 기존의 데이터 보안 방법은 클라우드 기반 아키텍처의 어려움을 겪고 있다. 탄력성, 다중 테넌시, 새로운 물리적, 논리적 아키텍처, 추상화 된 제어에는 새로운 데이터 보안 전략이 필요로 한다. 많은 클라우드 배포에서 사용자는 불과 몇 년 전까지만 해도 상상할 수 없었던 방식으로 외부 또는 공용 환경으로 데이터를 전송한다.

 

클라우드 컴퓨팅 시대에 정보를 관리하는 것은 모든 조직에 영향을 미치며 새로운 기술 보호뿐만 아니라 기본적인 거버넌스에 대한 새로운 접근방식을 요구하는 어려운 과제이다. 클라우드 컴퓨팅은 정보 거버넌스의 모든 영역에 적어도 어느 정도 영향을 미치지만 특히 제삼자와 작업하고 관할 구역을 관리하는데 있어 복잡성이 증가하기 때문에 규정 준수, 개인정보 보호 및 기업 정책에 특히 영향을 미친다.

 

정보 및 데이터 거버넌스 요구사항에 영향을 미치는 데이터를 클라우드에 저장하는 데에는 여러 가지 요구사항이 있다.

 

 멀티 테넌시(Multitenancy): 멀티 테넌시는 복잡한 보안 의미를 제공한다. 데이터가 퍼블릭 클라우드에 저장되면 신뢰할 수 없는 다른 테넌시와 공유인프라(Shared IT)에 저장된다. 사설 클라우드 환경에서도 서로 다른 사업부에서 공유되는 인프라에 저장 및 관리되므로 거버넌스 요구사항이 다를 가능성이 높다.

 보안 책임 공유(Shared Security Responsibility): 환경 공유가 증가하면 보안 공유에 대한 책임도 커진다. 데이터는 다른 팀이나 조직에 의해 소유되고 관리될 가능성이 높다. 따라서 데이터 관리자와 데이터 소유권 간의 차이를 인식하는 것이 중요하다.

☞ 이름에서 알 수 있듯이 소유권은 누가 데이터를 소유하는지에 관한 것이다. 항상 완벽하고 명확한 것은 없으며, 고객이 데이터를 제공하는 경우, 법률, 계약 및 정책에 따라 데이터를 합법적으로 소유할 수 있다. 공용 클라우드 공급자에서 데이터를 호스팅하는 경우 데이터를 소유해야 하지만, 이는 계약에 따라 달라질 수 있다.

☞ 관리자는 데이터를 관리하는 사람을 말하며, 개인정보를 제공하고 이를 소유할 권리가 없는 경우 단지 관리자일 뿐이다. 즉, 승인된 방식으로만 사용할 수 있다. 퍼블릭 클라우드 공급자를 사용하는 경우 자신이 구현하고 관리하는 규제에 따라 관리 책임이 있을 수 있으며, 공급자를 이용한다고 해서 책임이 사라지지는 않는다. 소유자와 관리자 간의 경계와 역할은 공공 클라우드의 경우 클라우드의 인프라 영향을 받는다.

 

클라우드로의 전환을 계획하기 전에 정보에 대한 거버넌스 요구사항을 결정해야 한다. 여기에는 법적 및 규제 요구사항, 계약 의무 및 기타 기업 정책이 포함되어 있다. 제 3자가 데이터를 처리 할 수 있도록 회사 정책 및 표준을 업데이트 해야 할 수 있다. 또한, 정보 거버넌스 정책 및 관행이 클라우드로 확장되는지 확인해야 하며, 이는 계약 및 보안 규제를 통해 수행된다. 필요한 경우 데이터 보안 수명 주기를 사용하여 데이터 처리 및 규제를 모델링 해야한다. 기존 정보 아키텍처를 해제하고 이동하는 대신 클라우드로 마이그레이션하여 기존 인프라에서 자주 사용되는 분리된 접근방식을 재구성해야 한다.

 

6 관리 기준면과 비즈니스의 연속성(Management Plane and business Continuity)

 

관리영역은 기존 인프라와 클라우드 컴퓨팅 간의 가장 중요한 보안 차이점이다. 이것은 모든 메타 구조가 아니라 메타 구조와 연결하고 많은 클라우드를 구성하기 위한 인터페이스를 의미한다.

 

 관리영역(메타구조) 보안

 API 게이트웨이 및 웹 콘솔에 대한 강력한 경계 보안이 있는지 확인한다.

 강력한 인증과 MFA를 사용한다.

 기본 계정 소유자/루트 계정 자격 증명을 엄격하게 제어하고, 이중 권한을 고려하여 액세스한다.

 제공업체에 여러 계정으로 구축하면 계정 세분화와 Blast radius 제한에 도움이 될 것이다.(IaaS 및 PaaS 사용)

 루트/기본 계정 소유자 자격 증명 대신 별도의 슈퍼관리자(최고관리자) 및 일상적인 관리자 계정을 사용한다.

 메타 구조 액세스를 위한 최소 권한의 계정들을 일관되게 설정한다.

 클라우드 공급자와 개발 및 테스트 계정을 분리한다.

 가능할 때마다 MFA 사용을 시행한다.

 

7 인프라 보안(Infrastructure Security)

 

인프라 보안은 클라우드에서 안전하게 운영하기 위한 기본 베이스이다. 해당 파트에서는 워크로드 및 하이브리드 클라우드가 포함된 컴퓨팅 및 네트워킹 보안을 다룬다. 스토리지 보안도 인프라의 핵심이지만 ‘2.11 데이터 보안 및 암호화’에서 자세히 다룰 예정이다. 또한 사설 클라우드 컴퓨팅의 기본사항도 다루고 있으며, 기존 표준과 지침들이 적용되어있는 데이터센터 보안에 대한 모든 구성 요소를 포함하지는 않는다.

 

인프라 보안은 물리적 시설에서 소비자의 인프라 요소 구성 및 구현에 이르기까지 가장 낮은 보안 계층을 포함하고 있다. 클라우드 제공업체 및 사설 클라우드 배포에서 참조해야 하는 데이터센터 보안에 대한 지식과 산업 표준은 이미 있지만 CSA 지침들은 인프라 보안의 클라우드 관련 측면에 초점을 맞추고 있다. 해당 파트에서는 기본 인프라에 대한 클라우드 고려 사항과 가상 네트워크 및 워크로드에 대한 보안이라는 2가지 측면에 대한 설명이 포함되어 있다.

 

해당 파트에서 제공업체 또는 플랫폼의 인프라 보안에 대해 다음과 같이 추천한다.

 

 공유 보안 모델에서 공급자(또는 사설 클라우드 플랫폼을 유지 관리하는 사람)는 클라우드의 기본 물리적, 추상화 및 오케스트레이션 계층을 보호해야 한다.

 규정 준수에 대한 인증 및 증명을 검토한다.

 공급업체가 클라우드 인프라의 모범사례나 규정을 따르고 있는지 확인하기 위해 정기적으로 산업 표준 및 산업별 규정 준수항목 등을 확인한다.

 네트워크는 가능한 SDN을 선호한다.

 여러 가상 네트워크 및 클라우드 계정/세그먼트에 SDN 기능을 사용하여 네트워크를 분리한다.

 별도의 계정과 가상 네트워크는 기존 데이터센터에 비해 Blast radius를 제한한다.

 네트워크 단위가 아니 워크로드 단위로 클라우드 방화벽을 적용한다.

 가능한 경우 클라우드 방화벽(보안 그룹) 정책을 사용하여 동일한 가상 서브넷에 있는 워크로드 간의 트래픽을 제한한다.

 탄력성을 제한하거나 성능 저하를 유발하는 가상 어플라이언스에 대한 종속성을 최소화 한다.

 가능할 때마다 변경 불가능한 워크로드를 활용하고, 장기간 실행되는 워크로드에 대해 보안 제어 기능을 유지하되 클라우드를 인식하는 툴을 사용하며, 외부에 로그를 저장한다.

 취약성 평가 및 해킹 테스트에 대한 클라우드 제한 사항을 이해하고 준수한다.

 

8 가상화 및 컨테이너(Virtualization and Containers)

 

가상화는 단순히 가상 머신을 생성하는 도구가 아닌 클라우드 컴퓨팅을 가능하게 하는 핵심 기술이다. 운영 가상머신에서 JVM(Java Virtual Machine)과 같은 실행환경은 물론 스토리지, 네트워킹 등 컴퓨팅 전반에 걸쳐 가상화가 가능하다.

 

클라우드 컴퓨팅은 기본적으로 리소스 풀링을 기반으로 하며, 고정 인프라를 이러한 풀링된 리소스로 변환하는데 사용되는 기술이다. 가상화는 리소스 풀에 필요한 추상화를 제공하며, 리소스 풀은 조직화 되어 관리하게 된다.

 

가상화가 보안에 미치는 영향을 이해하는 것은 클라우드 보안을 적절하게 설계하고 구현하는데 필수적이다. 리소스 풀에서 프로비저닝 된 가상 자산은 물리적 자산과 비슷해 보일 수 있지만 이러한 모양과 느낌은 실제로 보는 것보다 더 잘 이해하고 관리하는데 도움이 되는 도구일 뿐이다. 또한 운영체제와 같은 기존 기술을 활용할 수 있는 유일한 방법이다.

 

클라우드 공급자는 가상화에 사용되는 기본 물리적 인프라를 보호해야 하고, 테넌트 간의 보안 확보에 집중하여야 한다. 또한 클라우드 사용자가 자산을 적절하게 보호할 수 있도록 가상화 계층에서 충분한 보안 기능을 제공해야 하고, 물리적 인프라와 가상 플랫폼을 공격이나 내부 손상으로부터 보호해야 한다. 또한 기본 보안 구성만으로도 모든 고객 관리 가상화 기능이 구현되어야 한다.

 

클라우드 사용자는 클라우드 제공업체가 제공하는 기능과 보안 허점을 이해해야 하며, 클라우드 제공업체의 지침 및 기타 업계 모범사례에 따라 가상화 서비스를 적절하게 구성해야 한다.

 

9 사고 대응(Incident Response)

 

사고대응(IR: Incident Response)은 정보 보안 요소에서 중요한 부분이다. 예방적 보안으로는 중요한 데이터가 손상될 가능성을 완전히 제거할 수 없다는 것은 이미 입증 되었다. 대부분의 조직은 공격을 조사하는 방법을 통제하기 위한 일종의 IR 계획을 세우고 있으며, 클라우드 포렌식 데이터에 대한 액세스와 거버넌스에서 뚜렷한 차이를 나타내므로 조직은 IR 프로세스가 어떻게 변경되는지 신중하게 고려해야 한다.

 

해당 파트는 클라우드 컴퓨팅의 고유한 특성으로 발생하는 IR에 대해 분석한다. 보안 전문가는 IR 라이프 사이클의 준비 단계에서 대응 계획을 개발하고 다른 활동을 수행할 때 해당 파트를 참조할 수 있다. 이 파트는 National Institute of Standards and Technology Computer Security Incident Handling Guid(NIST 800-61rev2 08/2012)에 설명된 대로 일반적으로 허용되는 사고대응 수명 주기에 따라 구성된다. 사고 대응을 위한 다른 국제 표준 프레임 워크로 ISO/IEC 27035와 사고 대응 및 사이버 위기 협력을 위한 ENISA 전략이 있다.

 

SLA 및 고객이 하는 일 대비 제공업체가 하는 일에 대한 기대 설정은 클라우드 기반 리소스에 대한 사고 대응의 가장 중요한 측면이다. 각자의 역할과 책임을 명확하게 전달하고 사고에 대한 대응 연습하는 것이 중요하다. 클라우드 고객은 사고 발생 시 활용할 수 있는 공급자와의 비상 연락망을 가지고 있어야 한다. 또한 클라우드 고객은 클라우드 기반 리소스에 대한 지속적인 서비스 모니터링을 함으로서 기존 데이터센터보다 빠르게 잠재적인 문제들을 감지해야 한다.

 

클라우드 서비스 공급자의 SLA는 엔터프라이즈 사고 대응 계획을 효과적으로 실행하는데 필요한 지원을 보장해야 한다. 이는 감지, 분석, 봉쇄, 근절 및 복구와 같은 각각의 사고처리 프로세스 단계들이 포함되어 있다.

 

테스트는 적어도 1년에 한 번 또는 애플리케이션 아키텍처에 중대한 변경이 있을 때마다 수행되어야 한다. 고객들은 가능한 그들의 시험 절차들을 공급업체 및 다른 파트너들의 시험 절차와 통합 수행하여야 한다.

 

10 애플리케이션 보안(Application Security)

 

애플리케이션 보안은 초기 설계 및 위협 모델링에서 프로덕션 애플리케이션 유지 관리 및 보호에 이르기까지 매우 복잡하고 방대한 지식 체계를 포괄하고 있다. 또한, 애플리케이션 개발 관행이 계속해서 발전하고 새로운 프로세스, 패턴 및 기술을 수용함에 따라 애플리케이션 보안은 매우 빠른 속도로 진화하고 있다. 클라우드 컴퓨팅은 이러한 발전의 가장 큰 원동력 중 하나이며, 이러한 발전이 가능한 한 안전하게 계속되도록 보장하기 위해 애플리케이션 보안 상태를 지속적으로 발전 시켜야 한다.

해당 파트는 클라우드 컴퓨팅 환경, 특히 PaaS 및 IaaS에서 애플리케이션을 안전하게 구축하고 배포하려는 소프트웨어 개발 및 IT 팀을 대상으로 한다. (해당 파트는 보안 SaaS 애플리케이션을 뒷받침하는데도 사용된다.)

 

클라우드 컴퓨팅은 대부분 애플리케이션에 보안 측면에서 이점을 제공하지만 대부분의 클라우드 기술 영역과 마찬가지로 클라우드에서 작동하도록 설계되지 않은 기존 프로세스 및 기술에 상응하도록 변경이 필요하다.

 

클라우드에 설치되는 애플리케이션은 정식 SDLC(Software Development Life Cycle: 소프트웨어 개발 생명 주기)가 없더라도 지속해서 배포할 수 있도록 하고, 배포 파이프라인에 보안을 자동화 하는 것을 고려해보아야 한다. 또한 위협 모델링, SAST(Static Application Security Testing: 소스파일을 검사하고 근본적인 원인을 식별) 및 DAST(Dynamic Application Security Testing: 실행중인 웹 애플리케이션 또는 서비스를 대상으로 제어된 공격을 시뮬레이션하여 실행중인 환경에서의 취약성을 식별)(퍼징 포함) 모두 통합되어야 한다. 테스트는 클라우드 환경에서 작동하도록 구성하되 저장된 API 자격 증명과 같이 클라우드 플랫폼에 특정한 문제를 테스트하도록 구성되어야 한다.

 

11 데이터 보안 및 암호화(Data Security and Encryption)

 

데이터 보안은 정보 및 데이터 거버넌스를 위한 주요 시행 도구이다. 클라우드 보안의 모든 영역과 마찬가지로 모든 것을 동등하게 보호하는 것은 적절하지 않으므로 클라우드의 사용은 리스크에 기반해야 한다. 해당 파트는 클라우드 관련 여부에 관계없이 전반적인 데이터 보안에 해당한다. 하지만 많은 조직은 중요 데이터의 전부는 아니지만 많은 데이터양을 제삼자에게 공급하거나 내부 데이터를 공유 리소스 풀에 혼합하는데 익숙하지는 않다. 따라서 이러한 사항은 안전하고 비용적으로 효율적인 위험 기반 접근방식을 고수하는 대신 ‘클라우드의 모든 것’에 대한 포괄적인 보안 정책을 설정해야 한다.

 

예를 들어 SaaS의 모든 것을 암호화하는 것은 해당 공급자를 전혀 신뢰하지 않는 것으로 처음부터 공급업체를 사용해서는 안된다는 것을 의미할 수 있다. 하지만 모든 것을 암호화 하는 것이 만병통치약이 아니듯 기기 자체의 보안을 보장하지 않고 데이터 트래픽을 암호화 하는 등 잘못된 보안 의식을 초래할 수 있다.

 

어떤 관점에서의 정보 보안은 데이터에 대한 보안이지만, 해당 파트는 데이터 자체의 보안과 관련된 정책에 초점을 맞추고 있으며, 그 중 암호화가 가장 중요한 것 중에 하나로 나타내고 있다.

 

클라우드 제공업체 데이터 보안을 무시하지 말아야 하며, 대부분의 경우 직접 구축하는 것보다 클라우드 제공업체의 보안이 더 안전하고 비용도 저렴하다. 액세스 제어를 결정하기 위한 자격 매트릭스를 만들어야 하며, CASB(Cloud Access Security Broker: 클라우드 접근 보안 중계)를 고려하여 SaaS로 유입되는 데이터를 모니터링 하여야 한다. 일부 PaaS 및 IaaS에는 여전히 도움이 될 수 있지만, 이러한 유형의 대규모 마이그레이션에 대해서는 기존 정책 및 데이터 저장소 보안에 더 많이 의존하고 있다. 데이터, 비즈니스 및 요구사항에 대한 위협 모델에 따라 적절한 암호화 옵션을 사용해야 하며 공급자 관리 암호화 및 저장 옵션을 사용할 것인지 고려해야 한다. 가능한 경우는 고객 키(Customer-managed key)를 사용하는 것이 좋다.

 

NIST SP-800-57과 ANSI X9.69 및 X9.73은 좋은 보안을 설정하고 암호화 및 키 관리 기술과 프로세스를 올바르게 사용하는데 도움이 되는 표준이다.

 

12 ID, 사용 권한 및 액세스 관리(Identity, Entitlement, and Access Management)

 

ID, 사용 권한 및 액세스 관리(IAM)는 클라우드 컴퓨팅의 영향을 많이 받는다. 공공이나 개인 클라우드 모두에서 보안을 손상시키지 않고 IAM을 관리해야 한다. 이 파트에서는 클라우드의 ID 관리에서 변경해야 하는 사항에 중점을 두고 있다. 몇 가지 기본 개념을 검토하는 동안 클라우드가 ID 관리를 변경하는 방법과 이에 대해 수행할 작업에 중점을 둔다.

 

사설 클라우드에서의 주요 차이점은 공급자와 사용자 간의 관계이다. IAM은 둘 중 하나에 의해서만 관리 될 수 없으므로 신뢰 관계, 책임 지정 및 이를 가능하게 하는 기술적 메커니즘이 필요하다. 클라우드는 앞으로도 빠르게 변화하고 더욱 광범위한 네트워크 통신에 의존하여 핵심 인프라를 관리할 것이다.

 

본 파트는 주로 조직과 클라우드 제공업체 간 또는 제공업체와 서비스 간의 IAM에 대해 중점적으로 다룬다. IaaS에서 실행되는 엔터프라이즈 애플리케이션을 위한 내부 IAM과 같은 클라우드 애플리케이션 내 모든 면의 IAM에 대해서는 설명하지 않는다.

 

조직은 클라우드 서비스를 통해 ID와 권한을 관리하기 위한 포괄적이고 공식화 된 계획 및 프로세스 등을 개발해야 한다. 외부 클라우드 공급자에게 연결 할 때 가능한 경우 페더레이션을 사용하여 기존 ID 관리를 확장해야 한다. 또한 내부 ID에 연결되지 않은 클라우드 공급자의 ID를 최소화 해야 한다.

 

클라우드 사용자는 모든 외부 클라우드 계정에 대해 MFA를 선호하고 연합 인증을 사용할 때 MFA 상태를 속성으로 보내야 한다. 또한 권한이 잇는 ID는 항상 MFA를 사용해야 한다.

 

메타 구조나 관리 플레인에 대한 액세스를 강조하여 각 클라우드 공급자 및 프로젝트에 대한 권한 매트릭스를 만들어야 한다. 클라우드 컴퓨팅의 경우 RBAC보다 ABAC를 선호한다. 도한 클라우드 제공업체는 개방형 표준을 사용하여 내부 ID와 페더레이션을 모두 제공해야 한다고 이야기 하고 있다.3

 

13 서비스로서의 보안(Security as a Service)

 

해당 파트에서는 클라우드 플랫폼 및 배포 보안에 중점을 두지만 클라우드에서 제공되는 보안 서비스를 다루기 위한 내용을 포함하고 있다. 일반적으로 SaaS 또는 PaaS인 서비스는 클라우드 배포를 보호하기 위해 반드시 사용되어야 하는 것은 아니다. 기본적으로 온 프레미스 인프라를 방어하는데 도움이 된다는 의미이다.

 

SaaS 제공업체는 보안 기능을 클라우드 서비스로 제공한다. 여기에는 전용 SECaaS 공급자는 물론 일반 클라우드 컴퓨팅 공급자의 패키지 보안 기능이 포함된다. 서비스로서의 보안은 매우 광범위하지만 아래와 같은 기준을 충족해야 한다.

 

SECaaS에는 클라우드 서비스로 제공되는 보안 제품 또는 서비스가 포함되어야 한다.

SECaaS로 간주하려면 서비스가 2.1에 정의된 클라우드 컴퓨팅의 필수 NIST 특성을 충족해야 한다.

 

해당 파트에서는 SECaaS의 일부를 강조하고 있지만 다루지 않은 예외 서비스가 존재하며, 더욱 많은 서비스가 지속적으로 시장에 출시되기 때문에 해당 부분은 지속적으로 업데이트 할 필요가 있다.

 

SECaaS 공급자와 협조하기 전에 데이터 처리 및 가용성, 조사 및 규정 준수에 대한 보안 요구사항을 이해해야 한다. PII(Personally Identifiable Information: 개인식별정보)와 같은 규제 데이터 처리에는 특히 주의해야 한다. 데이터 보존 요구사항을 이해하고 종속 상황을 만들지 않는 데이터 피드를 지원할 수 있는 공급자를 선택해야 한다. SECaaS 서비스가 지원되는 클라우드 플랫폼, 워크 스테이션 및 모바일 운영체제 등과 호환이 되는지 확인해야 한다.

 

14 관련 기술(Related Technologies)

 

해당 파트는 클라우드 컴퓨팅을 직접 보호하기 위한 배경 정보와 모범사례를 제공하는데 초점을 맞추었다. 클라우드의 모든 잠재적인 부분까지 다루는 것은 본 문서의 범위를 많이 벗어난다. CSA는 클라우드와 관련된 핵심 기술에 대한 배경 및 환경 개선 사항을 포함하는 것이 중요하다고 생각한다. 컨테이너 및 소프트웨어 정의, 네트워크와 같은 부분은 각 매우 밀접하게 얽혀있어 다양한 지침들의 영역에서 다루고 있다.

 

해당 파트에서는 Bigdata, Internet of Things(IoT), Mobile, Serverless Computing 등에 대해 다루고 있다.

 

빅데이터 보안 기능 도구와 겹치는 경우에도 가능하면 클라우드 공급자가 제공하는 보안을 활용하는 것이 좋다. 이를 통해 클라우드 메타 구조 및 특정 애플리케이션 스택 내에서 적절한 보호를 받을 수 있다. 데이터 수집 및 데이터 스토리지 플레인 모두에 대해 기본, 중간 및 백업 스토리지에 암호화를 사용하고, 자격 매트릭스에 빅데이터 도구와 클라우드 플랫폼 ID 및 액세스 관리도 포함된다. 빅데이터 보안은 CSA에서 제공하는 사항을 포함하여 추가 빅데이터 보안 모범사례를 따르도록 한다.

 

IoT에서는 장치를 패치하고 업그레이드 할 수 있는지 확인해야 한다. 클라우드 애플리케이션 또는 인프라를 손상시킬 수 있는 장치에 정적 인증서를 저장하면 안된다. 일반적으로 페더레이션 된 ID 표준을 사용하여 클라우드 측 애플리케이션에 대한 보안 장치 등록 및 인증을 위한 모범사례들을 따라야 한다. CSA Internet of Things Working Group에서 발행한 자세한 추가 지침들을 따르도록 한다.

 

클라우드 인프라에 직접 연결되는 애플리케이션을 설계할 때 모바일 장치를 올바르게 인증하고 승인하는 방법에 대한 클라우드 제공업체의 지침을 따라야 한다. 모바일 장치 애플리케이션을 클라우드 호스팅 애플리케이션에 연결하기 위해 일반적으로 페더레이션 ID인 산업 표준을 사용한다. 모바일에서는 인터넷을 통해 암호화되지 않은 키 또는 자격 증명을 전송하면 안된다. 또한 적대적인 공격자가 인증되고 암호화되지 않은 액세스 권한을 갖는다는 가정하에 모든 API를 테스트 해야 한다. CSA Mobile Working Group에서 발행한 보다 자세한 권장 사항을 따르도록 한다.

 

클라우드 제공업체는 어떤 PaaS 서비스가 어떤 규정 준수, 요구사항 또는 표준에 대해 평가되었는지 명확하게 명시되어야 한다. 클라우드 사용자는 규정 준수 및 거버넌스 의무와 일치하는 서버리스 서비스만 사용해야 하며, 공격 측면이나 네트워크 공격 경로를 제거하는 아키텍처를 사용하여 애플리케이션 스택에 서버리스 구성 요소를 삽입하는 것을 고려해야 한다. 또한, 클라우드 사용자는 서버 및 네트워크 로그보다는 애플리케이션 코드 스캔 및 로깅 더 많이 신경을 써야 한다. 또한, 서버리스 배포를 위해 사고 대응 프로세스를 주기적으로 업데이트 해야 한다. 클라우드 공급자는 서버리스 플랫폼 수준 이하의 보안을 담당하고 있지만 클라우드 사용자는 제품을 올바르게 구성하고 사용할 책임을 지고 있다.

 

 

728x90
반응형

'Study > Technology Issues' 카테고리의 다른 글

클라우드 시장(Cloud market) 현황  (0) 2023.03.23
Web 3.0 IPFS 분산파일 시스템  (0) 2023.03.17
Web 3.0 기술 중 IPFS 기술에 대해  (0) 2023.03.17
ChatGPT 아시나요?  (0) 2022.12.12
qmil 설치방법  (0) 2019.09.03

댓글()

Web 3.0 IPFS 분산파일 시스템

Study/Technology Issues|2023. 3. 17. 17:33
728x90
반응형

 

IPFS (InterPlanetary File System)의 기술에는 다음과 같은 것들이 있다.

분산 파일 시스템: IPFS는 파일을 여러 노드에 저장하므로 중앙 집중형 방식과 달리 한 대의 서버가 다운되더라도 다른 노드에서 파일을 검색할 수 있어 안정성이 높다.

해시 기반 파일 검색: IPFS는 파일을 검색할 때 파일의 해시 값을 이용하여 검색하며, 저장된 파일을 가져오기 위해서는 해당 파일의 해시 값을 이용하여 노드들 중 하나에 요청을 보내면 된다.

블록체인 기술과의 결합: IPFS는 블록체인과의 결합으로 보안성과 신뢰성을 높일 수 있다. 블록체인에는 기록의 불변성이 보장되기 때문에, IPFS에서 저장된 파일에 대한 변경이나 위조가 발생했을 경우 블록체인을 통해 검증할 수 있다.

암호화 파일 저장: IPFS에서는 파일을 암호화하여 저장할 수 있으므로 파일의 안전성을 보장할 수 있다.

HTTP와 유사한 프로토콜: IPFS는 HTTP와 유사한 프로토콜을 사용하여 파일을 저장하고 검색할 수 있다.

오픈 소스: IPFS는 오픈 소스로 제공되며, 다양한 툴킷과 라이브러리를 제공하여 개발자들이 쉽게 사용할 수 있다.

사용자 중심의 인터넷 구조: IPFS는 분산형 구조를 채택하고 있으며, 이를 통해 사용자 중심의 인터넷 구조를 구현할 수 있다.

IPFS의 기술은 파일 저장 및 검색 시스템에서 적용 가능하며, 이러한 기술은 대용량 파일 처리 및 분산형 구조 구현 등 다양한 분야에서 응용 가능하다.

 

 


python을 예로

 

IPFS의 Python API인 Py-IPFS-HTTP-API를 이용하여 IPFS에 파일을 저장하는 예제 코드를 작성해보겠습니다.

먼저, Py-IPFS-HTTP-API를 설치합니다.

 

pip install ipfshttpclient

 

다음은 파일을 IPFS에 저장하는 코드입니다.

 

import ipfshttpclient

# IPFS 연결
client = ipfshttpclient.connect('/ip4/127.0.0.1/tcp/5001/http')

# 파일 추가
res = client.add('example.txt')

# 결과 출력
print(res)

 

 

위의 코드에서는 IPFS에 로컬 파일 시스템에 있는 example.txt 파일을 추가하고, 결과를 출력하는 예제 코드입니다. res 변수에는 추가된 파일의 해시 값과 크기 등의 정보가 담긴 객체가 반환됩니다.

이와 같이 Py-IPFS-HTTP-API를 이용하면 Python에서도 IPFS를 쉽게 이용할 수 있습니다.

728x90
반응형

'Study > Technology Issues' 카테고리의 다른 글

클라우드 시장(Cloud market) 현황  (0) 2023.03.23
CSA(Cloud Security Alliance) Publication 이란?  (0) 2023.03.23
Web 3.0 기술 중 IPFS 기술에 대해  (0) 2023.03.17
ChatGPT 아시나요?  (0) 2022.12.12
qmil 설치방법  (0) 2019.09.03

댓글()

Web 3.0 기술 중 IPFS 기술에 대해

Study/Technology Issues|2023. 3. 17. 17:28
728x90
반응형

 

IPFS (InterPlanetary File System)는 분산형 파일 저장 및 검색 시스템으로, 블록체인과 유사한 분산형 기술을 활용하여 파일의 신뢰성과 안정성을 보장하는 기술이다.

기존의 파일 저장 방식은 중앙 집중형 방식으로, 파일을 저장하는 서버가 중앙에 위치해 있다. 이 방식은 서버에 문제가 발생하면 해당 서버의 파일에 접근이 불가능하게 되는 문제가 있다. 또한, 대량의 파일을 저장해야 할 경우 서버의 용량 한계로 인해 추가적인 서버를 구축해야 하므로 비용적으로 부담이 된다.

이에 반해 IPFS는 파일을 여러 노드에 저장하므로 중앙 집중형 방식과 달리 한 대의 서버가 다운되더라도 다른 노드에서 파일을 검색할 수 있어 안정성이 높다. 또한 파일이 중복 저장되지 않기 때문에 저장 용량의 효율성도 높다. 또한 IPFS는 파일을 저장할 때 파일의 해시 값을 기반으로 저장하므로 파일의 무결성을 보장할 수 있다.

IPFS는 HTTP와 유사한 프로토콜을 사용하여 파일을 저장하고 검색할 수 있다. 파일을 검색할 때는 파일의 해시 값을 이용하여 검색하며, 저장된 파일을 가져오기 위해서는 해당 파일의 해시 값을 이용하여 노드들 중 하나에 요청을 보내면 된다. 이렇게 검색과 저장이 분산되어 처리되므로 서버 부하 문제와 같은 문제를 해결할 수 있다.

IPFS는 블록체인 기술과의 결합으로 보안성과 신뢰성을 높일 수 있다. 블록체인에는 기록의 불변성이 보장되기 때문에, IPFS에서 저장된 파일에 대한 변경이나 위조가 발생했을 경우 블록체인을 통해 검증할 수 있다. 또한 IPFS에서는 파일을 암호화하여 저장할 수 있으므로 파일의 안전성 또한 보장할 수 있다.

IPFS는 대용량의 파일을 저장하고 검색해야 하는 다양한 분야에서 활용될 수 있다. 예를 들어, 빅데이터 분야에서는 IPFS를 활용하여 대용량의 데이터를 저장하고 검색할 수 있다. 또한, 게임, 음악, 영화 등의 산업에서도 IPFS를 활용하여 분산형 파일 저장 시스템을 구축하여 파일의 안정성과 신뢰성을 높일 수 있다.

 

IPFS는 오픈 소스로 제공되며, 다양한 툴킷과 라이브러리를 제공하여 개발자들이 쉽게 사용할 수 있다. 또한, IPFS의 기술이 대규모로 확산되면 기존의 인터넷 구조가 대대적으로 변화될 수 있다. IPFS는 분산형 구조를 채택하고 있으며, 이를 통해 사용자 중심의 인터넷 구조를 구현할 수 있다. 이러한 구조는 개인 정보 보호, 무결성 검증, 서버 부하 분산 등 다양한 이점을 제공할 수 있다.

하지만 IPFS의 기술은 아직 미완성 상태이며, 개발자들이 계속해서 발전시켜 나가고 있다. 또한, IPFS의 사용이 일반적으로 보급되면서 보안 문제와 같은 문제가 발생할 수 있다. 이러한 문제들은 보안 강화와 이용 방법의 개선으로 해결될 수 있다.

IPFS는 분산형 파일 저장 및 검색 시스템으로, 기존의 중앙 집중형 파일 저장 시스템과 달리 안정성과 효율성을 보장한다. 또한, 블록체인과의 결합으로 보안성과 신뢰성을 높일 수 있다. 이러한 기술은 다양한 분야에서 활용될 수 있으며, 인터넷 구조의 대대적인 변화를 가져올 수 있다. IPFS의 발전과 함께 더욱 안정적이고 신뢰성 높은 파일 저장 및 검색 시스템의 구현이 가능할 것으로 예상된다.

 

IPFS (InterPlanetary File System)의 기술에는 다음과 같은 것들이 있다.

  1. 분산 파일 시스템: IPFS는 파일을 여러 노드에 저장하므로 중앙 집중형 방식과 달리 한 대의 서버가 다운되더라도 다른 노드에서 파일을 검색할 수 있어 안정성이 높다.
  2. 해시 기반 파일 검색: IPFS는 파일을 검색할 때 파일의 해시 값을 이용하여 검색하며, 저장된 파일을 가져오기 위해서는 해당 파일의 해시 값을 이용하여 노드들 중 하나에 요청을 보내면 된다.
  3. 블록체인 기술과의 결합: IPFS는 블록체인과의 결합으로 보안성과 신뢰성을 높일 수 있다. 블록체인에는 기록의 불변성이 보장되기 때문에, IPFS에서 저장된 파일에 대한 변경이나 위조가 발생했을 경우 블록체인을 통해 검증할 수 있다.
  4. 암호화 파일 저장: IPFS에서는 파일을 암호화하여 저장할 수 있으므로 파일의 안전성을 보장할 수 있다.
  5. HTTP와 유사한 프로토콜: IPFS는 HTTP와 유사한 프로토콜을 사용하여 파일을 저장하고 검색할 수 있다.
  6. 오픈 소스: IPFS는 오픈 소스로 제공되며, 다양한 툴킷과 라이브러리를 제공하여 개발자들이 쉽게 사용할 수 있다.
  7. 사용자 중심의 인터넷 구조: IPFS는 분산형 구조를 채택하고 있으며, 이를 통해 사용자 중심의 인터넷 구조를 구현할 수 있다.

IPFS의 기술은 파일 저장 및 검색 시스템에서 적용 가능하며, 이러한 기술은 대용량 파일 처리 및 분산형 구조 구현 등 다양한 분야에서 응용 가능하다.

728x90
반응형

'Study > Technology Issues' 카테고리의 다른 글

CSA(Cloud Security Alliance) Publication 이란?  (0) 2023.03.23
Web 3.0 IPFS 분산파일 시스템  (0) 2023.03.17
ChatGPT 아시나요?  (0) 2022.12.12
qmil 설치방법  (0) 2019.09.03
미래융합기술포럼 및 성과전시회  (0) 2012.11.28

댓글()

ChatGPT 아시나요?

Study/Technology Issues|2022. 12. 12. 13:07
728x90
반응형

https://chat.openai.com/chat

 

 

 

네이버 지식인과 같이 궁금한 질문에 대해 답변을 해주는 chat 기능입니다. 

 

 

 

궁금해서 간단하게 질문을 해보았는데... 답변이 의외로 자세히 나오네요~

 

문제는 너무 사용자가 많은것 같습니다.  아니면 서버가 뒷받침이 안되나봐요~

 

메뉴는 총 4가지가 있는데 

 

reset Thread는 초기화로 처음으로 다시 돌아가는거고.. 

 

Light mode는 배경 변경 시 사용합니다. 

 

OpenAI discord 는 discord로 연결 할 수 있으며 봇을 사용할 수 있게 되어 있네요~ 나중에 api 활용 시 좋을 것 같습니다. 

 

나머지는 뭐 질의와 로그 아웃으로 되어 있네요~ㅎ

 

지금도 계속 질의를 남기고 있는데 request가 너무 많아 답변을 안해줘요~ㅠㅠ

728x90
반응형

댓글()

qmil 설치방법

Study/Technology Issues|2019. 9. 3. 15:06
728x90
반응형

qmail이 무엇인가?

큐메일은 기존의 sendmail 을 대체하는 메일 전송 에이전트( MTA )로써 보다 안정적이며 속도 향상을 가져다 줄 수 있습니다. 기존의 sendmail 에서 할 수 없었던 많은 기능이 포함되어 있습니다.

주요기능

- 무한정 도메인과 pop 메일 아이디를 발급 할 수 있습니다.

- 한 개의 시스템 계정생성으로 모든 버츄얼 도메인, pop 계정을 만들수 있습니다.

- 불필요한 유저 생성을 막을 수 있습니다. (보안적인 측면에 유리합니다.)

- 각 도메인마다 메일 계정, 메일링 리스트의 한계를 설정 할 수 있다.

- 웹인터페이스로 메일 추가, 삭제, 메일링 및 각 도메인에 대한 메일 관리가 가능합니다.

- 유저별 quota 설정이 가능합니다. 

- 각 도메인 관리자가 자기 도메인의 메일 계정 추가 삭제가 가능합니다.

- 가상 메일 없이도 도메인마다 똑같은 사용자 계정을 만들 수 있습니다.

위의 내용은 웹호스팅용 메일 시스템으로 아주 유리한 기능들이며 이밖에 다양한 기능들을 내포하고 있습니다.

필요한 프로그램 및 다운로드 사이트

qmail-1.03.tar.gz (http://cr.yp.to)

ucspi-tcp-0.88-man.tar.gz (http://cr.yp.to/ucspi-tcp/install.html)

daemontools-0.76-man.tar.gz (http://cr.yp.to/daemontools/install.html)

vpopmail-5.2.1.tar.gz (http://inter7.com/vpopmail)

qmailadmin-1.0.6.tar.gz (http://inter7.com/qmailadmin)

autorespond-2.0.2.tar.gz (http://inter7.com/qmailadmin)

ezmlm-0.53.tar.gz (http://www.ezmlm.org)

ezmlm-idx-0.40.tar.gz (http://www.ezmlm.org)

qmail-smtpd-auth-0.31.tar.gz (http://members.elysium.pl)

qmail-103.patch (http://cr.yp.to)

설치환경

버전 : CentOS 4.3

qmil 설치파일 다운로드 경로 : /root

( 1 ) 다운로드

qmail 설치에 필요한 파일들을 다운로드 합니다.

wget은 웹에서 자동적으로 파일을 받아오는데 사용되는 유틸리티이며 HTTP, HTTPS, FTP 프로토콜을 지원합니다.

① qmail-1.03.tar.gz 다운로드

[root@nextline ~]# wget http://cr.yp.to/software/qmail-1.03.tar.gz

 

② ucspi-tcp-0.88.tar.gz 다운로드

[root@nextline ~]# wget http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz

 

③ daemontools-0.76.tar.gz 다운로드

[root@nextline ~]# wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz

 

④ vpopmail-5.2.1.tar.gz 다운로드

[root@nextline ~]# wget http://www.inter7.com/vpopmail/vpopmail-5.2.1.tar.gz

 

⑤ qmailadmin-1.0.6.tar.gz 다운로드

[root@nextline ~]# wget http://www.inter7.com/qmailadmin/qmailadmin-1.0.6.tar.gz

 

⑥ autorespond-2.0.2.tar.gz 다운로드

[root@nextline ~]# wget http://www.inter7.com/devel/autorespond-2.0.2.tar.gz

 

⑦ ezmlm-0.53.tar.gz 다운로드

[root@nextline ~]# wget http://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-patches/ezmlm-0.53.tar.gz

 

⑧ ezmlm-idx-0.40.tar.gz 다운로드

[root@nextline ~]#wget http://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-patches/ezmlm-idx-0.40.tar.gz

 

⑨ qmail-smtpd-auth-0.31.tar.gz 다운로드

[root@nextline ~]# wget http://members.elysium.pl/brush/qmail-smtpd-auth/dist/qmail-smtpd-auth-0.31.tar.gz

 

⑩ qmail-1.03.patch 다운로드

[root@nextline ~]# wget http://www.ckdhr.com/ckd/qmail-103.patch

 

( 2 ) qmail 설치

① qmail-1.03.tar.gz 파일의 압축을 해제합니다.

[root@nextline ~]# tar zxvf qmail-1.03.tar.gz

 

② qmail-smtpd-auth-0.31.tar.gz 파일의 압축을 해제합니다.

[root@nextline ~]# tar zxvf qmail-smtpd-auth-0.31.tar.gz

 

③ qmail-stmp-auth-0.31 패치

qmail-smtpd-auth-0.31 디렉토리로 이동합니다.

[root@nextline ~]# cd qmail-smtpd-auth-0.31

qmail-smtpd-auth-0.31 패치 파일을 qmail-1.03 디렉토리로 복사합니다.

[root@nextline qmail-smtpd-auth-0.31]# cp README.auth base64.c

base64.h ../qmail-1.03

qmail-1.03를 패치합니다.

[root@nextline qmail-smtpd-auth-0.31]# patch -d ../qmail-1.03 < auth.patch

 

④ dns 패치

qmail-1.03 디렉토리로 이동합니다.

[root@nextline ~]# cd qmail-1.03

qmail-1.03.patch 패치를 적용합니다.

[root@nextline qmail-1.03]# patch -p1 < ../qmail-103.patch

 

⑤ qmail 디렉토리 및 INSTALL.ids 파일 편집

qmail이 설치될 디렉토리를 생성합니다.

[root@nextline qmail-1.03]# mkdir /var/qmail

vi 에디터 사용법

사용형식 : vi [옵션] [생성할 파일명/편집할 파일명]

vi 에디터는 입력모드, 명령모드, 실행모드로 구분됩니다.

입력모드 : vi 편집화면에서 문자를 입력할 수 있는 모드로서 입력모드로 진입하기 위해서는 i, a, o, I, A, O, R등이 있습니다. 즉 초기 vi 편집기 모드는 명령어 모드로 진입을 하기때문에 문자를 입력하기 전에 앞의 단축키 중 하나를 먼저 입력해야 원하는 문자를 입력할 수 있습니다.

명령모드 : 커서이동/문자삭제/문자()교체/문자열검색 등을 할수 있는 모드로서 입력모드에서 편집이 완료되면 Esc키를 눌러 명령모드로 진입하면 됩니다.

x : vi 명령모드에서 커서위치의 한 문자 삭제

dw : vi 명령모드에서 커서위치의 한단어 삭제

dd : vi 명령모드에서 커서위치의 행 삭제

Ndd : vi 명령모드에서 커서위치의 여러행 동시 삭제

실행모드 : 특별한 명령어를 실행하는 모드로서 명령어모드에서 ":"(콜론)를 누르면 vi 화면 하단 좌측에 vi 특수명령어를 입력할 수 있습니다.

실행모드의 일반적으로 쓰이는 특수 명령어

q : 수정 작업이 이루어지지 않은 상태에서 vi 편집기에서 빠져나옵니다.

q! : 수정 작업이 이루어진 부분을 적용시키지 않고 vi 편집기를 강제로 빠져나옵니다.

w : 수정된 작업을 저장합니다.

wq : 수정된 작업을 저장하고 vi 편집기에서 빠져나옵니다.

초기 명령어모드 -> 입력모드진입 -> 편집 -> 명령어모드 -> 실행모드 -> 종료

qmail 계정 및 그룹을 생성하기 위해 INSTALL.ids 파일을 편집합니다. 아래와 같이 리눅스에 해당하는 라인을 제외하고는 모두 삭제 합니다.

INSTLL.ids파일을 편집합니다. 아래와 같이 Linux 부분을 제외한 나머지 부분을 삭제한 후 저장하고 vi에디터를 빠져나옵니다.

[root@nextline qmail-1.03]# vi INSTALL.ids 

 

⑥ qmail 그룹 및 계정생성

sh INSTALL.ids 실행으로 위의 편집한 qmail 그룹 및 계정이 자동 생성됩니다.

[root@nextline qmail-1.03]# sh INSTALL.ids

 

컴파일

[root@nextline qmail-1.03]# make 

 

make 오류 발생시 qmail-1.03.errno.patch패치 파일을 다운로드 하여 패치를 합니다.

qmail 패치파일 다운로드

http://qmail.kldp.org/src/patches/glibc-2.3.1/

 

패치파일 다운로드

오류 해결을 위해 qmail-1.03.errno.patch 패치 파일을 다운로드 합니다.

[root@nextline qmail-1.03]# wget http://qmail.kldp.org/src/patches/glibc-2.3.1/?id=1687

 

⑨ qmail-1.03.errno.patch 파일로 패치를 적용합니다.

[root@nextline qmail-1.03]# patch –p1 < qmail-1.03.errno.patch

 

⑩ qmail-1.03.errno.patch 패치 후 재 컴파일 합니다.

[root@nextline qmail-1.03]# make

 

설치

[root@nextline qmail-1.03]# make setup check

 

⑫ ./config-fast 도메인

컴파일/설치가 끝나면 기본 control 파일들의 설정을 위해 다음 명령어를 실행합니다.

정상적으로 실행 되었다면 /var/qmail/control/ 안에는 qmail이 정상적으로 작동하기 위한 설정 파일들이 생기게 됩니다.

[root@nextline qmail-1.03]#./config-fast nextline.co.kr

 

⑬ /var/qmail/control 설정화일 확인

[root@nextline qmail-1.03]# ls /var/qmail/control/

 

( 3 ) ucspi-tcp 설치

tcpserver tcpclient TCP 클라이언트-서버 응용 프로그램을 만들기 위한 명령행

도구들의 모음입니다.

① ucspi-tcp-0.88-man.tar.gz 파일의 압축을 해제 합니다.

[root@nextline ~]# tar zxvf ucspi-tcp-0.88.tar.gz

 

컴파일

압축해제된 ucspi-tcp-0.88 디렉토리로 이동합니다.

[root@nextline ~]# cd ucspi-tcp-0.88

ucspi-tcp를 컴파일 합니다.

[root@nextline ucspi-tcp-0.88]# make

 

make: *** [tcpserver] 오류 발생시 ucspi-tcp-0.88.errno.patch 패치를 합니다.

패치파일 다운로드

http://qmail.kldp.org/src/patches/glibc-2.3.1/

③ ucspi-tcp-0.88.errno.patch 패치파일 다운로드

[root@nextlijne ucspi-tcp-0.88]# wget http://qmail.kldp.org/src/patches/glibc-2.3.1/?id=1692

 

④ ucspi-tcp-0.88.errno.patch 패치를 적용합니다.

[root@nextline ucspi-tcp-0.88]# patch -p1 < ucspi-tcp-0.88.errno.patch

 

⑤ ucspi-tcp-0.88.errno.patch 파일 패치 후 재 컴파일 합니다.

[root@nextline ucspi-tcp-0.88]# make

 

설치

[root@nextline ucspi-tcp-0.88]# make setup check

 

( 4 ) daemontools 설치

daemontools는 시스템 서비스를 관리하기 위한 도구들의 모음으로 ucspi-tcp와 같이 사

용하면 inetd/xinetd 같은 구시대 수퍼 데몬을 완전히 대체할 수 있습니다.

① daemontools-0.76.tar.gz 파일의 압축을 해제 합니다.

Daemontools 설치 할 디렉토리를 생성합니다.

[root@nextline ~]# mkdir -p /package

디렉토리 퍼미션을 변경합니다.

[root@nextline ~]# chmod 755 /package/

daemontools-0.76.tar.gz 파일을 /package 디렉토리로 이동합니다.

[root@nextline ~]# cp daemontools-0.76.tar.gz /package/

/package 디렉토리로 이동합니다.

[root@nextline ~]# cd /package/

daemontools-0.76.tar.gz 파일의 압축을 해제 합니다.

[root@nextline package]# tar zxvf daemontools-0.76.tar.gz

 

설치

압축를 해제하면 admin 디렉토리와 daemontools-0.76 디렉토리가 생성됩니다.

admin 디렉토리 하위 daemontools-0.76 디렉토리로 이동합니다.

[root@nextline package]# cd admin/daemontools-0.76/

Package/install 명령으로 daemontoos를 설치합니다.

[root@nextline daemontools-0.76]# package/install

 

make 오류시

make: *** [envdir] 오류 패치를 합니다.

패치파일 다운로드

http://qmail.kldp.org/src/patches/glibc-2.3.1/

③ daemontools-0.76.errno.patch 패치파일을 다운로드 합니다.

[root@nextline daemontools-0.76]# wget http://qmail.kldp.org/src/patches/glibc-2.3.1/?id=1668

 

④ daemontools-0.76.errno.patch 패치를 적용합니다.

[root@nextline daemontools-0.76]# patch -p1 < daemontools-0.76.errno.patch

 

⑤ daemontools-0.76.errno.patch 패치 후 package/install 를 재 실행합니다.

[root@nextline daemontools-0.76]# package/install

 

( 5 ) autorespond 설치

메일의 자동 응답을 해줄 수 있게 하는 프로그램입니다.

압축해제

autorespond-2.0.2.tar.gz 파일이 위치한 /root 디렉토리로 이동합니다.

[root@nextline daemontools-0.76]# cd /root

autorespond-2.0.2.tar.gz 파일의 압축을 해제 합니다.

[root@nextline ~]# tar zxvf autorespond-2.0.2.tar.gz

 

컴파일

압축 해제된 autorespond-2.0.2 디렉토리로 이동합니다.

[root@nextline ~]# cd autorespond-2.0.2

컴파일을 합니다.

[root@nextline autorespond-2.0.2]# make

 

③ autorespond 파일 복사

[root@nextline autorespond-2.0.2]# cp autorespond /usr/local/bin/

 

( 6 ) qmail 데몬을 위한 디렉토리 및 스크립트 파일 생성

스크립트생성

[root@nextline ~]# vi /var/qmail/rc

 

아래의 스크립트를 추가합니다.

#!/bin/sh

exec env - PATH="/var/qmail/bin:$PATH" \

qmail-start ./Maildir/

 

디렉토리 생성 및 퍼미션 변경

생성한 rc 파일의 실행권한을 줍니다.

[root@nextline ~]# chmod a+x /var/qmail/rc

qmail 데몬을 위한 디렉토리와 권한을 줍니다.

[root@nextline ~]# mkdir -p /var/qmail/supervise/qmail-send/log

[root@nextline ~]# mkdir -p /var/qmail/supervise/qmail-smtpd/log

[root@nextline ~]# chmod +t /var/qmail/supervise/qmail-send

[root@nextline ~]# chmod +t /var/qmail/supervise/qmail-smtpd

 

스크립트 생성

[root@nextline ~]# vi /var/qmail/supervise/qmail-send/run

 

아래의 스크립트를 추가합니다.

#!/bin/sh

exec /var/qmail/rc

 

스크립트 생성

[root@nextline ~]# vi /var/qmail/supervise/qmail-send/log/run

 

아래의 스크립트를 추가합니다.

#!/bin/sh

exec /usr/local/bin/setuidgid qmaill \

/usr/local/bin/multilog t /var/log/qmail

 

스크립트 생성

[root@nextline ~]# vi /var/qmail/supervise/qmail-smtpd/run

 

스크립트를 추가합니다.

#!/bin/sh

Q_UID=`id -u vpopmail`

Q_GID=`id -g vpopmail`

exec /usr/local/bin/softlimit -m 7340032 \

/usr/local/bin/tcpserver -vRHl 0 \

-x /home/vpopmail/etc/tcp.smtp.cdb \

-u $Q_UID -g $Q_GID 0 25 /var/qmail/bin/qmail-smtpd nextline.co.kr \

/home/vpopmail/bin/vchkpw /bin/true 2>&1

 

# 주의 : vRHl 0 (L의 소문자, 숫자 0), 인용문자가‘(작은따옴표)가 아니고 `(숫자1옆에 있는 것) 입니다.

스크립트 생성

[root@nextline ~]# vi /var/qmail/supervise/qmail-smtpd/log/run

 

삽입 스크립트

#!/bin/sh

exec /usr/local/bin/setuidgid qmaill \

/usr/local/bin/multilog t /var/log/qmail/smtpd

 

편집한 파일들에 실행권한을 주기 위해 퍼미션를 변경합니다.

[root@nextline autorespond-2.0.2]# chmod 755 /var/qmail/supervise/qmail-send/run

[root@nextline autorespond-2.0.2]# chmod 755 /var/qmail/supervise/qmail-send/log/run

[root@nextline autorespond-2.0.2]# chmod 755 /var/qmail/supervise/qmail-smtpd/run

[root@nextline autorespond-2.0.2]# chmod 755 /var/qmail/supervise/qmail-smtpd/log/run

 

⑧ qmail-smtpd를 위한 로그 디렉토리 생성 및 소유권 변경

[root@nextline /]# mkdir -p /var/log/qmail/qmail-smtpd

[root@nextline /]# chown qmaill /var/log/qmail/ /var/log/qmail/qmail-smtpd/

 

기본 alias 계정 생성 및 퍼미션변경

[root@nextline alias]# echo postmaster > /var/qmail/alias/.qmail-root

[root@nextline alias]# echo postmaster > /var/qmail/alias/.qmail-postmaster

[root@nextline alias]# echo postmaster > /var/qmail/alias/.qmail-mailer-daemon

[root@nextline alias]# cd /var/qmail/alias/

[root@nextline alias]# chmod 644 .qmail-root .qmail-postmaster .qmail-mailer-daemon

 

⑩ qmail 시동스크립트 생성

[root@nextline ~]# vi /etc/rc.d/init.d/qmail

 

아래의 스크립트를 추가합니다.

#!/bin/sh

# For Red Hat chkconfig

# chkconfig: - 80 30

# description: the qmail MTA

PATH=/var/qmail/bin:/bin:/usr/bin:/usr/local/bin:/usr/local/sbin

export PATH

case "$1" in

start)

echo "Starting qmail"

if [ -e /service/qmail-send ] ; then

if svok /service/qmail-send ; then

svc -u /service/qmail-send

else

echo qmail-send supervise not running

fi

else

ln -s /var/qmail/supervise/qmail-send /service/

fi

if [ -e /service/qmail-smtpd ] ; then

if svok /service/qmail-smtpd ; then

svc -u /service/qmail-smtpd

else

echo qmail-smtpd supervise not running

fi

else

ln -s /var/qmail/supervise/qmail-smtpd /service/

fi

if [ -d /var/lock/subsys ]; then

touch /var/lock/subsys/qmail

fi

;;

stop)

echo "Stopping qmail..."

echo " qmail-smtpd"

svc -dx /service/qmail-smtpd /service/qmail-smtpd/log

rm -f /service/qmail-smtpd

echo " qmail-send"

svc -dx /service/qmail-send /service/qmail-send/log

rm -f /service/qmail-send

if [ -f /var/lock/subsys/qmail ]; then

rm /var/lock/subsys/qmail

fi

;;

stat)

svstat /service/qmail-send

svstat /service/qmail-send/log

svstat /service/qmail-smtpd

svstat /service/qmail-smtpd/log

qmail-qstat

;;

doqueue|alrm|flush)

echo "Flushing timeout table and sending ALRM signal to qmail-send."

/var/qmail/bin/qmail-tcpok

svc -a /service/qmail-send

;;

queue)

qmail-qstat

qmail-qread

;;

reload|hup)

echo "Sending HUP signal to qmail-send."

svc -h /service/qmail-send

;;

pause)

echo "Pausing qmail-send"

svc -p /service/qmail-send

echo "Pausing qmail-smtpd"

svc -p /service/qmail-smtpd

;;

cont)

echo "Continuing qmail-send"

svc -c /service/qmail-send

echo "Continuing qmail-smtpd"

svc -c /service/qmail-smtpd

;;

restart)

echo "Restarting qmail:"

echo "* Stopping qmail-smtpd."

svc -d /service/qmail-smtpd

echo "* Sending qmail-send SIGTERM and restarting."

svc -t /service/qmail-send

echo "* Restarting qmail-smtpd."

svc -u /service/qmail-smtpd

;;

cdb)

tcprules /home/vpopmail/etc/tcp.smtp.cdb /home/vpopmail/etc/tcp.smtp.tmp < /home/vpopmail/etc/tcp.smtp

chmod 644 /home/vpopmail/etc/tcp.smtp.cdb

echo "Reloaded /home/vpopmail/etc/tcp.smtp."

;;

help)

cat <

stop -- stops mail service (smtp connections refused, nothing goes out)

start -- starts mail service (smtp connection accepted, mail can go out)

pause -- temporarily stops mail service (connections accepted, nothing leaves)

cont -- continues paused mail service

stat -- displays status of mail service

cdb -- rebuild the tcpserver cdb file for smtp

restart -- stops and restarts smtp, sends qmail-send a TERM & restarts it

doqueue -- schedules queued messages for immediate delivery

reload -- sends qmail-send HUP, rereading locals and virtualdomains

queue -- shows status of queue

alrm -- same as doqueue

flush -- same as doqueue

hup -- same as reload

HELP

;;

*)

echo "Usage: $0 {start|stop|restart|doqueue|flush|reload|stat|pause|cont|cdb|queue|help}"

exit 1

;;

esac

exit 0

 

퍼미션 변경

[root@nextline ~]# chmod 755 /etc/rc.d/init.d/qmail

 

chkconfig ntsysv를 이용한 서비스 자동실행

시스템이 시작할 때 불필요하거나 사용하지 않는 서비스를 실행하지 않게 하는 방법 중 최근에 많이 쓰이는 명령어로 chkconfig가 있습니다. chkconfig 명령어를 이용하면 시스템에 설치되어 있는 모든 서비스 데몬을 확인할 수 있고, 특정 서비스를 쉽게 활성화하거나 해제할 수 있습니다.

[root@nextline ~]# chkconfig --list

시스템에 설치되어 있는 모든 서비스 데몬을 확인할 수 있습니다.

[root@nextline ~]# chkconfig --level 2345 sendmail off

런레벨 2~5에서 sendmail을 해제합니다.

[root@nextline ~]# chkconfig --level 2345 nfs on

런레벨 2~5에서 nfs 서비스를 활성화합니다.

[root@nextline ~]# chkconfig rlogin off

xinetd 기반의 서비스인 rlogin을 해제합니다.

--add --del 스위치를 사용해서 서비스를 추가하거나 삭제할 수 있습니다. chkconfig는 단지 설정 파일을 변경하여, 시스템을 부팅했을 때 해당 서비스 데몬의 실행 여부만 결정하는 것이므로, 다앙 서비스를 시작시키거나 중지시키려면 반드시 service 명령을 사용해야 한다. 참고로 service 명령어는 다음과 같이 사용합니다.

service 서비스명 {start | stop | restart | reloal}

레드햇에는 chkconfig외에도 ntsysv라는 조금은 오래된 툴이 있다. 이 툴은 시스템을 재시작할 때 자동으로 시작할 데몬을 [*]로 체크해서 손쉽게 지정할 수 있다.

⑫ qmail 서비스를 추가합니다.

[root@nextline ~]# chkconfig –-add qmail

ntsysv

ntsysv RunLevel을 조정할 수 있는 편리한 인터페이스를 제공하는 툴입니다.

그냥 쉘 프롬프트에서 ntsysv 라고 입력하면 됩니다. 새로 나온 화면에서 부팅 시

자동으로 띄우고싶은 데몬은 체크를 하면 됩니다.

부팅시 qmail를 자동 실행시키기 위해 ntsysv를 실행합니다.

[root@nextline ~]# ntsysv

 

부팅시 qmail 시작될 수 있도록 [*] qmail 체크를 하고 [확인] 를 눌러 빠져나옵니다.

 

기존의 pop3 데몬을 사용하지 않음으로 설정합니다.

[root@nextline ~]# vi /etc/xinetd.d/pop3

 

아래와 같이 disable = yes 로 설정하면 xinetd를 시작하여도 pop3 데몬이 실행되지 않습니다.

service pop3

{

disable = yes

flags = REUSE

socket_type = stream

wait = no

user = root

server = /usr/local/lib/popper

server_args = qpopper -s

log_on_failure += USERID

}

( 7 ) vpopmail 설치

vpopmail 은 가상 도메인 추가, 설정, pop 유저 설정과 pop3 데몬등의 기능을 하며 vpopmail이 제대로 작동하려면 vpopmail이 사용할 유저와 그룹을 만들어야 한합니다.

① vpopmail 유저 및 그룹생성

vchkpw 그룹을 생성합니다.

[root@nextline ~]# groupadd vchkpw

vchkpw 그룹에 속한 vpopmail 계정을 생성합니다.

[root@nextline ~]# useradd -g vchkpw vpopmail

이때 생성되는 vpopmail 홈 디렉토리에는 앞으로 추가할 도메인들의 모든 이메일 계정, 메일들이 저장될 곳이므로, 공간이 넉넉한 파티션을 고르는 것이 좋겠다. 다른 파티션을 사용할 것이라면 다음과 같이 할수 있습니다. 디렉토리를 지정하지 않으면 기본 /home파티션에 계정 홈디렉토리가 생성됩니다.

[root@nextline ~]#useradd -g vchkpw -d /원하는/파티션의/디렉토리를/지정 vpopmail

 

② vpopmail-5.2.1.tar.gz 압축을 해제합니다.

[root@nextline ~]# tar zxvf vpopmail-5.2.1.tar.gz

 

③ vmysql.h 편집

mysql vpopmail 메일의 연동을 하지 않으시려면 ③,④번을 적용하지 않습니다.

mysql과 연동하기 위한 설정입니다.

MySQL db를 사용하려 한다면, 컴파일 하기전에 먼저 vmysql.h 를 열어서 sql 서버를 액세스할수 있는 user와 암호등을 설정해 주어야 합니다. vpopmail 상위 버젼에서는 아

래와 같은 라인이 없다면 설치 후 /home/vpopmail/etc/vpopmail.mysql에 설정해 줍니다. 테이블을 생성/삭제 할 수 있는 사용자 이여야하므로 보통 root 나 해당 유저로

설정해 줍니다.

압축 해제된 vpopmail-5.2.1 디렉토리로 이동합니다.

[root@nextline ~]# cd vpopmail-5.2.1

mysql 연동을 위해 vmysql.h 파일을 편집합니다.

[root@nextline vpopmail-5.2.1]# vi vmysql.h

 

아래 부분을 편집합니다.

/* Edit to match your set up */

#define MYSQL_UPDATE_SERVER "localhost"

#define MYSQL_UPDATE_USER "vpopmail" <- mysql 생성 계정명

#define MYSQL_UPDATE_PASSWD "xxxxxx" <- 계정 패스워드

#define MYSQL_READ_SERVER "localhost"

#define MYSQL_READ_USER "vpopmail" <- mysql 생성 계정명

#define MYSQL_READ_PASSWD "xxxxxx" <- 계정 패스워드

/* End of setup section*/

 

④ mysql 계정 생성

위에서 설정한 vmysql.h user와 패스워드를 동일하게 생성하여야 합니다.

vpopmail DB 계정 생성을 위해 mysql에 접속합니다.

[root@nextline ~]# mysql -u root -p

mysql 패스워드를 입력합니다.

Enter password:

mysql 사용자로 로그인 합니다.

mysql> use mysql;

vpopmail 데이터베이스를 생성합니다.

mysql> create database vpopmail;

vpopmail 데이터베이스의 사용자명과 vpopmail계정의 패스워드를 입력합니다.

mysql> grant all privileges on vpopmail.* to vpopmail@"localhost" identified by 'xxxxxx';

위에서 생성한 vpopmail 데이터베이스 정보를 적용합니다.

mysql> flush privileges;

mysql를 빠져나옵니다.

mysql> quit

 

⑤ vpopmail 환경설정 옵션

vpopmail 5.0 이상 버젼은 --enable-large-site 옵션이 --enable-many-domains

으로 바뀌었습니다. , 각 도메인별로 테이블을 생성관리 할 것이라면 --enable-many-domains=n 옵션을 사용합니다.

vpopmail 5.0 이하 버젼은 --enable-large-site=n|y 옵션을 사용할 수도 있는데 이것은, 디폴트로 vpopmail 은 모든 도메인, 유저 정보를 한개의 테이블에서 관리합니다. 만약 각각의 도메인에 많은 메일 유저가 있다면 y로 설정하면, vpopmail은 도메인별로 테이블을 생성,유저 정보를 관리합니다.

--enable-mysql=y 옵션은 mysql과 연동을 위한 옵션입니다. 만약 sql 헤더파일이나 라이브러리를 찾지 못한다며 컴파일에 실패한다면, --enable-sqlincdir= sql 헤더파일 경로. --enable-sqllibdir= sql 라이브러리 경로 등을 ./configure 할때 추가 해줍니다.

예에서 nextline.co.kr 는 주 서버의 도메인 이름이다. 이것을 설정하면 주 서버의 메일 계정도 모두 가상 도메인의 메일 계정과 동일하게 관리 할 수 있다.

--enable-ip-alias-domains=y

ip aliasing을 사용하여 각 도메인마다 각기 다른 ip를 사용할 것이라면 옵션을 추가합니다.

--enable-roaming-users=y

로밍 서비스를 사용할 것이라면 옵션을 추가합니다.

vpopmail pop 서버의 로그 조절 옵션

아무런 옵션을 주지 않고 컴파일 했다면 vpopmail pop서버는 팝 유저들이 어떤 이유로든 로그인을 실패 했을 경우에만 로그를 남깁니다. (/var/log/maillog 또는 /var/log/messages)) 다음과 같은 옵션으로 로그 조절이 가능합니다.

--enable-logging=y : 모든 pop 로그인 기록과 오류 메시지를 남긴다.

--enable-logging=n : 아무런 로그도 남기지 않는다.

--enable-logging=e : 오류/ 치명적인 오류 메세지를 기록한다.

--enable-logging=p : 오류 로그에 암호를 포함한다.

--enable-logging=v : --enable-logging=y 와 같으며 사용자 암호를 로그에 포함한다.

[root@nextline vpopmail-5.2.1]# ./configure --enable-default-domain=nextline.co.kr --enable-mysql=y --enable-

incdir=/usr/local/mysql/include/mysql --enable-libdir=/usr/local/mysql/lib/mysql/ --enable-roaming-users=y --enable-tcprules-prog=/usr/local/bin/tcprules --enable-relay-clear-minutes=15

 

컴파일

[root@nextline vpopmail-5.2.1]# make

 

설치

[root@nextline vpopmail-5.2.1]# make install-strip

 

생성파일 확인

[root@nextline vpopmail-5.2.1]# ls /home/vpopmail/

 

⑨ SMTP 릴레이 설정

vpopmail의 로밍서비스는 고정되어 있지 않은 IP사용자들에게 smtp 릴레이를 지원해 줄수 있는 기능이다. vpopmail은 먼저 POP 메일 유저의 암호를 확인한다음 얼마만큼의 시간동안 그 IP주소의 smtp 릴레이를 열어 놓게 된다. 다음과 같이 기본적인 tcp.smtp 파일을 만든다.

다음 파일에는 qmail smtp 데몬이 메일을 중계(relay)할 주소를 추가합니다.

그외 메일을 중계 해줄 서버의 주소가 있다면 같은 형식으로 추가합니다.

vi /home/vpopmail/etc/tcp.smtp

------------------------------------------

127.0.0.1:allow,RELAYCLIENT=""

xxx.xxx.xxx.xxx:allow,RELAYCLIENT=""

:allow

------------------------------------------

첫 번째와 두번째줄은 메일 서버 내부의 릴레이를 열어 준 것입니다.

릴레이를 전혀 허용하지 않으려면 첫 번째와 두번째 룰만 있으면 됩니다.

xxx.xxx.xxx.xxx:allow,RELAYCLIENT="" 를 예를 들어 설명하면

tcpserver는 해당 ip (xxx.xxx.xxx.xxx)로 부터의 접속을 허용하고 (:allow)

해당 ip에서 접속이 있을 경우 RELAYCLIENT 환경 변수를 설정한 후 qmail-smtpd 를 실행하게 되므로 릴레이가 허용되는 원리 입니다.

마지막 줄의 :allow 는 다른 ip에서의 접속을 허용만 하고 RELAYCLIENT 환경 변수는 설정하지 않습니다.

, 릴레이는 허용하지 않습니다. (기본값이 allow입니다.)

[root@nextline vpopmail-5.2.1]# vi /home/vpopmail/etc/tcp.smtp

 

아래의 스크립트를 추가합니다.

127.0.0.:allow,RELAYCLIENT=""

xxx.xxx.xxx.xxx:allow,RELAYCLIENT="" < - xxx.xxx.xxx.xxx 로컬 ip를 입력합니다.

:allow

 

[root@nextline vpopmail-5.2.1]# tcprules /home/vpopmail/etc/tcp.smtp.cdb /home/vpopmail/etc/tcp.smtp.tmp < /home/vpopmail/etc/tcp.smtp

[root@nextline vpopmail-5.2.1]# /home/vpopmail/bin/clearopensmtp

 

cron에 의해 주기적으로 실행되어 릴레이가 허용된 IP 주소 중 pop 인증 시간이 한 시간 이상 된 것이 있으면 지워줍니다. vpopmail 컴파일 시 별다른 옵션을 주지 않았다면 기본적으로 릴레이 허용 시간은 한 시간이며 이것은 --enable-relay-clear-minutes= 옵션으로 바꿔 줄 수 있습니다.

⑩ crontab 등록

 

아래의 스크립트를 추가합니다.

# vpopmail clearopensmtp

40 * * * * /home/vpopmail/bin/clearopensmtp

 

⑪ pop3 시동파일 생성

[root@nextline ~]# mkdir /var/qmail/supervise/vpop

[root@nextline ~]# vi /var/qmail/supervise/vpop/run

 

삽입 스크립트

#!/bin/sh

VPOP_UID=`id -u vpopmail`

VPOP_GID=`id -g vpopmail`

exec /usr/local/bin/softlimit -m 7340032 \

tcpserver -vRHl 0 -u $VPOP_UID -g $VPOP_GID 0 110 \

/var/qmail/bin/qmail-popup nextline.co.kr \

/home/vpopmail/bin/vchkpw /var/qmail/bin/qmail-pop3d Maildir 2>&1

주의 : 인용문자가‘(작은따옴표)가 이나고 `(숫자1옆에 있는 것) 입니다.

 

⑫ qmail 데몬 시작하기

pop3 시동파일에 실행권한을 줍니다.

[root@nextline ~]# chmod 755 /var/qmail/supervise/vpop/run

만약 이전 sendmail이 아직 전송하지 못한 메일들이 메일 큐에 쌓여 있다면 sendmail -q 를 실행 시켜서 전송을 마쳐 주어야 합니다. 메일이 많이 쌓여 있을 경우 이것은 한번의 실행으로 끝나지 않을 수 도 있습니다.

/etc/rc.d/init.d/sendmail stop 으로 sendmail 데몬을 종료합니다.

[root@nextline ~]# ln -s /var/qmail/supervise/vpop /service

[root@nextline ~]# /etc/rc.d/init.d/sendmail stop

 

기존의 sendmail 바이너리를 qmail 의 것으로 바꿉니다.

[root@nextline ~]# mv /usr/lib/sendmail /usr/lib/sendmail.old

[root@nextline ~]# mv /usr/sbin/sendmail /usr/sbin/sendmail.old

[root@nextline ~]# ln -s /var/qmail/bin/sendmail /usr/lib

[root@nextline ~]# ln -s /var/qmail/bin/sendmail /usr/sbin

qmail를 시동합니다. 이렇게 /service 디렉토리에 링크를 한번 걸어주면 링크가 존재하는 한 즉, 재부팅 한다해도 daemontools에 의해서 자동으로 서비스가 시작됩니다.

[root@nextline ~]# ln -s /var/qmail/supervise/qmail-send /service/

[root@nextline ~]# ln -s /var/qmail/supervise/qmail-smtpd /service/

 

⑬ vpopmail를 이용한 도메인, 메일 계정 추가하기

/home/vpopmail/bin 디렉토리 안에 가상 도메인 관리를 위한 바이너리들이 있는데 다음과 같은 기능을 합니다.

[root@nextline ~]# ls /home/vpopmail/bin/

 

각 바이너리들의 용도

vadddomain

가상 도메인을 추가한다. postmaster 암호를 물어보는데 이것은 다음에 설치할 qmailadmin 웹 인터페이스에서 로그인 할때 물어볼 암호입니다.

vadddomain 도메인명

vdeldomain 가상 도메인과 모든 유저를 삭제합니다.

vdeldomain 도메인명

vadduser pop 메일 유저 계정을 만듭니다.

vadduser test@nextline.co.kr

vdeluser pop 메일 유저를 삭제합니다.

vdeluser test@nextline.co.kr

vpasswd 메일 유저의 암호를 변경합니다.

vpasswd test@nextline.co.kr

vsetuserquota 각 유저 별로 quota 설정을 할 수 있습니다.

vsetuserquota test@nextline.co.kr 51200 (단위는 byte 이다).

vpopbull 서버에 설정되어 있는 모든 유저들에게 한번에 메일을 보낼 때 유용하게 사용 할수 있습니다.

이제 도메인을 추가해 보도록 합니다. 위에서 주 도메인도 vpopmail에서 관리하기로 했다면 주 도메인과 메일 계정들도 추가해야 합니다.

만약 주 도메인이 nextline.co.kr 이고, 추가할 가상 도메인이 nextline1.co.kr, nextline2.co.kr 라고 한다면 다음과 같이 합니다. (추가하기 전에 가상 도메인들의 DNS MX 레코드의 IP주소가 주 서버로 되어있는지 확인 해보자).

./vadddomain nextline.co.kr

./vadddomain nextline1.co.kr

./vadddomain nextline2.co.kr

다음 qmail 설정 파일들이 제대로 바뀌었는지 확인해봅니다. 주 도메인도 vpopmail이 관리하기로 했다면 /var/qmail/control/locals 파일의 내용은 localhost 만이 있어야 정상입니다. qmail smtpd가 이 서버의 것이라고 인식하며 메일을 수신할 도메인들은 다음과 같이 rcpthosts 에 저장될 것입니다.

localhost

nextline.co.kr

nextline1.co.kr

nextline2.co.kr

virtualdomains 파일의 내용입니다.

nextline.co.kr:nextline.co.kr

nextline1.co.kr:nextline1.co.kr

nextline2.co.kr:nextline2.co.kr

/var/qmail/users/assign 의 내용입니다.

+nextline.co.kr-:nextline.co.kr:512:507:/home/vpopmail/domains/nextline.co.kr:-::

+nextline1.co.kr-:nextline1.co.kr:512:507:/home/vpopmail/domains/nextline1.co.kr:-::

+nextline2.co.kr-:nextline2.co.kr:512:507:/home/vpopmail/domains/nextline2.co.kr:-::

필요한 도메인, 메일 계정을 모두 추가하셨다면 qmail를 사용하기 위한 모든 프로그램 설치가 완료되었습니다.

( 8 ) qmail 테스트

ex) 도메인 : nextline.co.kr

계 정 : nextline

① vpopmail을 이용하여 가상도메인 및 유저를 생성해 보겠습니다.

[root@nextline ~]# cd /home/vpopmail/bin

[root@nextline bin]# ls

② nextline.co.kr 도메인을 생성합니다.

[root@nextline bin]# ./vadddomain nextline.co.kr

③ nextline.co.kr 도메인의 패스워드를 입력합니다. 이 패스워드가 qmailadmin에서 해당 도메인으로 접속 할때의 패스워드가 됩니다.

Please enter password for postmaster:

enter password again:

④ nextline 계정을 생성합니다.

[root@nextline bin]# ./vadduser nextline@nextline.co.kr

⑤ nextline 이메일 계정의 패스워드 입니다. 아웃룩 메일 계정 셋팅시 nextline 계정에 대한 패스워드 입니다.

Please enter password for nextline@nextline.co.kr:

enter password again:

 

⑥ Outlook Express 셋팅

아웃룩 익스프레스상에서 위 계정의 메일이 정상 송/수신 되는지 테스트합니다.

 

[도구] – [계정] – [인터넷계정] – [메일] – [추가] – [메일]

[표시이름] : 넥스트라인

[인터넷 전자메일주소] : nextline@nextline.co.kr

[받는메일] : mail.nextline.co.kr

[보내는 메일] : mail.nextline.co.kr

[계정이름] : nextline

[암호] : xxxxxx

[마침]

추가한 메일계정의 속성 탭을 선택합니다.

[속성] – [서버] – [인증필요 체크] –[적용] – [확인] –[닫기]

메일 보내기

[아웃룩 익스프레스] – [메일작성] – [보내기]

아래와 같이 생성한 메일 계정으로 메일을 보냅니다.

 

수신 확인

[배달] – [받은 편지함] 메일이 정상 수신되었습니다.

 

다음은 vpopmail의 웹 인터페이스이며 도메인의 추가,삭제를 제외한 모든 기능을 웹 상에서 할 수 있으며, ezmlm 을 이용한 메일링 리스트 추가, 삭제, 관리까지 할 수 있는 qmailadmin 설치를 하겠습니다.

( 9 ) ezmlm 설치

ezmlm qmail 과 같이 사용할 수 있는 강력한 메일링 리스트입니다.

① ezmlm-0.53.tar.gz 파일의 압축을 해제 합니다.

[root@nextline ~]# tar zxvf ezmlm-0.53.tar.gz

 

② ezmlm-idx-0.40.tar.gz 파일의 압축을 해제 합니다.

[root@nextline ~]# tar zxvf ezmlm-idx-0.40.tar.gz

 

③ ezmlm-idx-0.40 하위의 모든 파일을 ezmlm-0.53 디렉토리로 이동 합니다.

[root@nextline ~]# mv -f ezmlm-idx-0.40/* ezmlm-0.53

압축 해제된 ezmlm-0.53 디렉토리로 이동합니다.

[root@nextline ~]# cd ezmlm-0.53

⑤ idx.patch 패치를 적용합니다.

[root@nextline ezmlm-0.53]# patch < idx.patch

 

컴파일

[root@nextline ~]# make

 

make: *** [ezmlm-idx] 오류1

⑦ make 오류수정

[root@nextline ezmlm-0.53]# vi error.h

 

error.h파일의 아래의 구문를 추가합니다.

#include

 

재 컴파일

[root@nextline ezmlm-0.53]# make

 

⑨ make man

 

설치

[root@nextline ~]# make setup

 

( 9 ) qmailadmin 설치

① qmailadmin-1.0.6.tar.gz 파일의 압축을 해제 합니다.

[root@nextline ~]# tar zxvf qmailadmin-1.0.6.tar.gz

 

압축 해제된 qmailadmin-1.0.6 디렉토리로 이동합니다.

[root@nextline ~]# cd qmailadmin-1.0.6

컴파일 하기위한 환경 설정을 합니다.

--enable-cgibindir

qmailadmin 이 설치될 디렉토리이다. 웹서버가 사용중인 cgi-bin 디렉토리를 적어줍니다. 디폴트는 /usr/local/apache/cgi-bin 입니다.

--with-htmllibdir

qmailadmin html 템플레이트 파일들이 저장될 장소입니다. 그냥 디폴트로 놔두어도 됩니다. (default /usr/local/share/qmailadmin)

--enable-cgipath

사용중인 웹서버의 cgi path /cgi-bin/ 이 아닌 경우 설정해줍니다. 디폴트는 /cgi-bin/qmailadmin 이다.

컴파일을 하기 위한 환경설정을 합니다.

[root@nextline qmailadmin-1.0.6]# ./configure --enable-cgibindir=/usr/local/apache/cgi-bin/

 

컴파일

[root@nextline qmailadmin-1.0.6]# make

 

설치

[root@nextline qmailadmin-1.0.6]# make install-strip

 

⑥ qmailadmin cgi생성 확인

[root@nextline qmailadmin-1.0.6]# ls /usr/local/apache/cgi-bin/

 

⑦ httpd.conf 편집

qmailadmin 설치시 --with-htmllibdir 옵션을 사용하지 않으면 기본 /usr/local/apa

che/htdoc 디렉토리에 images 디렉토리가 생성됩니다.

[root@nextline bin]# vi /usr/local/apache/conf/httpd.conf

 

아래 구문을 VirtualHost부분에 추가합니다.

NameVirtualHost xxx.xxx.xxx.xxx

 

가상 도메인 생성

여기서 생성한 도메인이 qmailadmin 로그인시 사용될 도메인과 패스워드입니다.

가상 도메인 추가를 위해 /home/vpopmail/bin 디렉토리로 이동합니다.

[root@nextline ~]# cd /home/vpopmail/bin

nextline.co.kr 가상 도메인을 생성합니다.

[root@nextline bin]# ./vadddomain nextline.co.kr

Postmaster 패스워드를 입력합니다.

Please enter password for postmaster:

Enter password again:

 

⑨ qmailadmin 한글화

기본 영문으로 되어 있는 언어를 한국어로 변환하기위해 en 파일을 카피하여 해석된 언

어를 ko파일에 추가합니다.

[root@nextline ~]# cd /usr/local/share/qmailadmin/html/

[root@nextline ~]# cp –a en ko

[root@nextline ~]# cat /dev/null > ko

[root@nextline ~]# vi ko

 

한글화 삽입

000 euc-ko

001 메인 메뉴

002 POP 어카운트

003 자동 응답 추가:

004 자동 응답명:

005 오너 메일 주소:

006 건명:

007 전송 어카운트 작성:

008 전송처 메일 주소:

009 로컬 유저명:

010 전송처 메일 주소는 이와 같은 형식이 되군요 안 되는 유저@domain.com

로컬 유저명은 이와 같은 형식이 되군요 안 되는 것:POP 어카운트

, 전송처: joe@test.com 로컬 유저명: sales()라면, sales@##D 앞 모든 메일을 joe@domain.com 전송한다고 함

011 모더레이터 추가

012 모더레이터를 리스트 추가

013 메일 주소:

014 참가자 추가

015 리스트 추가

016 리스트명

017 리스트 오너 주소:

018 어카이브(archive)한다고

019 어카이브(archive) 하지 않는 것

020 어카이브(archive)를 보호할.모더레이터만이 어카이브(archive)가 참조 끝남

021 어카이브(archive)는 참가자 , 보호 설정에 따르며 참조 끝날

022 정리하고 보낼 하지 않았다.정리하고 보내 리스트나 셋업 하지 않는것

023 프리픽스한다고(리스트로부터 메세지 건명 리스트명을 넣는)

024 프리픽스 하지 않는 것

025 어카이브(archive)를 보호할.인식 할 수 없는 것 송신자 요구는 거부함

026 어카이브(archive)를 보호하지 않는 것.송신자가 누구든, 어카이브(archive)를 참조끝남

027 참가로는 승인이 불요

028 참가에는 참가 주소가 메세지를 돌려주는 것에 의한다 승인이 필요

029 Web으로부터 어카이브(archive)를 참조 가능

030 Web 어카이브(archive) 없음

031 탈퇴가 승인은 불요

032 탈퇴 참가 주소가 메세지를 돌려주는 것에 의한다 승인이 필요

033 remote administration자는 참가자 리스트를 요구 끝나며 참가자 로그를 검색 끝날

034 참가자 리스트는 얻을 수 없는

035 투고로는 승인이 필요

036 투고로는 승인이 불요

037 모더레이터 의외로부터 투고는 거부 당할.이것은 승인이 필요한 리스트만 유효

038 거부는 당하고 않는.승인이 필요한 리스트에 있어서, 모든 투고는 모

더레이터 전송 당한다고.이 선택사항은 승인이 필요한 리스트에 두며 유효.

039 관리 요구 응답한, 어카이브(archive) 갱신을 허가할

040 remote administration자하게는, 다이제스트 작성, remote

administration, 어카이브(archive) 갱신만 허가(리스트가 이 옵션으로 작성 당했을 때)

041 관리 요구 응답한, 어카이브(archive) 갱신을 허가할

042 remote administration자하게는, 다이제스트 작성, remote

administration, 어카이브(archive) 갱신만 허가(리스트가 이 옵션으로 작성 당했을 때)

043 리퀘스트 주소를 이용 가능하게 하는

044 리퀘스트 주소앞 메세이지를 처리하지 않는 것

045 remote administration한다고

046 remote administration 하지 않는 것

047 참가 승인할

048 참가가 승인은 불요

049 Trailer

050 No trailer

051 유저는 투고만

052 송신자 주소로 제한하지 않는 것

053 SQL 서포트 유효

054 호스트

055 포토

056 유저

057 패스워드

058 데이타베이스

059 테이블

060 추가

061 POP 어카운트

062 어카운트

063 코멘트

064 수정 유저

065 어카운트삭제

066 Catch All어카운트

067 POP 어카운트 추가

068 별명 어카운트

069 별명

070 POP 어카운트

071 수정

072 삭제

073 별명 추가

074 전송 어카운트

075 전송

076 전송 추가

077 자동 응답

078 자동 응답

079 자동 응답 추가

080 메일링리스트

081 리스트

082 삭제

083 참가자추가

084 참가자삭제

085 참가자일람

086 모더레이터추가

087 모더레이터삭제

088 모더레이터일람

089 메일링리스트 추가

090 POP 어카운트 추가

091 패스워드(재입력):

092 실명

093 리스트명

094 참가자명

095 이하 메일링리스트 새로운 유저를 참가 시킬

096 별명 삭제

097 삭제 승인

098 자동 응답 삭제

099 SQL Settings

100 전송 삭제

101 메일링리스트 삭제

102 유저 삭제

103 전송

104 이하 전송합니다:

105 자동 응답 수정

106 이름

107 내용

108 추가 메일 주소

109 수정 유저

110 신패스워드

111 패스워드 변경

112 어카운트

113 도메인

114 로그인

115 리디렉트

116 현재 리디렉트

117 리디렉트를 추가/치환

118 리디렉트를 삭제

119 추가했습니까

120 추가 가능했습니다

121 별명

122 전송

123 리디렉트 일람

124 퀵 링크

125 POP 어카운트 추가

126 별명 추가

127 전송 추가

128 자동 응답 추가

129 메일링리스트

130 바운스가 있었던 것

131 이것으로 일람은 모두입니다.전페이지 돌아 주세요

132 설정

133 Index:

134 Chatch All 설정을 해제

135 전페이지

136 갱신

137 다음 페이지

138 패스워드를 입력하고 주세요

139 POP 어카운트의 패스워드를 변경했습니까

140 패스워드의 변경 실패했습니까

141 유저를 삭제했습니까

142 권한이 있지 않습니다

143 디렉토리 권한 에러

144 파일 권한 에러

145 내부 에러 부정확한 유저입니다

146 리디렉트 할 수 있지 않습니다

147 리디렉트한다고

148 부정확한 메일 주소입니다

149 마지막 엔트리를 삭제 끝났습니다

150 파일 에러

151 행을 삭제했습니까

152 전송명 %s 를 추가했습니까

153 유저명은 존재하지 않습니다

154 별명을 추가했습니까

155 부정확한 조작입니다

156 작성 끝날 별명 최대수에 이르렀던 것

157 작성 끝날 전송 최대수에 이르렀던 것

158 작성 끝날 자동 응답 최대수에 이르렀던 것

159 부정확한 DotQmail 입력 : adddotqmail()

160 부정확한 별명입니다

161 별명을 추가 끝났습니다.실재할 POP 어카운트명을 입력하고 주세요

162 부정확한 POP 어카운트명입니다

163 부정확한 로컬명입니다

164 부정확한 별명 입력 : adddotqmailnow()

165 별명 추가 실패했습니까

166 별명을 추가했습니까

167 별명/전송 %s 삭제 실패했습니까

168 별명/전송 %s 는 삭제 당했습니까

169 리디렉트/전송 삭제 실패했습니까

170 리디렉트/전송을 삭제했습니까

171 에러: 디렉토리를 변경 끝났습니다 %s\n

172 한 번 한사람 밖에 postmaster로서 로그인 끝나지 않습니다 다른 누군

가가 로그인하고 있습니다. 나중에 로그인해 보세요

173 로그인은 끊어졌습니다, 재로그인해 주세요 \n

174 부정확한 자동 응답명입니다

175 그 이름은 이미 사용되고 있습니다.

176 자동 응답명을 입력하여 주세요

177 부정확한 메일 주소 오너입니다

178 건명을 입력하고 주세요

179 송신할 메세지를 무엇인가 입력하고 주세요

180 자동 응답이 추가 당했습니까 자동 응답

181 자동 응답 삭제 실패했습니까

182 자동 응답이 삭제 당했습니까

183 자동 응답이 수정 당했습니까 %s

184 작성 끝날 메일링리스트가 최대수에 이르렀음

185 파일을 삭제 끝났습니다.

186 메일링리스트를 삭제하겠습니까?

187 메일링리스트를 추가하겠습니까?

188 부정확한 메일 리스트명입니다

189 메일링리스트상 메일 주소 리스트

190 리스트 종단

191 메일링리스트상 모더레이터 메일 주소 리스트

192 메인 메뉴에

193 메일링리스트가 메일 주소가 추가 했습니까?

194 메일링리스트가 모더레이터 메일 주소가 추가 했습니까?

195 메일링리스트로부터 참가자 주소가 삭제 했습니까?

196 메일링리스트로부터 모더레이터를 삭제

197 메일링리스트로부터 모더레이터 주소가 삭제 했습니까?

198 부정확한 로그인입니다

199 작성 끝날 POP 어카운트 최대수에 이르렀던 것

200 패스워드가 일치하지 않습니다. 재입력해주세요

201 메모리 부족이 발생하고 있습니다

202 파라미터(parameter):

203 메일 주소는 메일링리스트로부터 삭제 하겠습니까?

204 Go user

205 전달 및 부재 해제

206 Set remote catch all account

207 Set Remote CatchAll

208 Remote CatchAll Address:

209 전달 여부 설정

210 Email 복사본 저장후 전달 설정/해제

211 Email 전달:

212 부재 설정/해제

213 부재중 응답 제목:

214 부재중 응답 내용:

215 Must supply forward address

216 Must supply subject

217 메뉴 새로 고침

218 로그 아웃

219 List Moderators

220 Moderator

Address

221 List Subscribers

222 Subscriber

Address

223 Could not find user

224 (click to modify)

225 Modify Mailing List

226 Mailing list modified successfully

227 Digest

228 Total:

229 unlimited

230 Total Subscribers:

231 No Mailing Lists to Display

232 No Aliases/Forwards to Display

233 No Mail Robots to Display

 

접속 테스트

http://ip/cgi-bin/qmailadmin

 

qmailadmin 로그인 화면

 

qmailadmin pop 계정 추가화면

이와 같이 qmailadmin 웹 인터페이스를 이용하면 가상도메인별 계정 관리가 편리 합니다

 

 


728x90
반응형

댓글()

미래융합기술포럼 및 성과전시회

Study/Technology Issues|2012. 11. 28. 08:37
728x90
반응형


미래융합기술포럼 및 성과전시회가 11월 26~27일 이틀간 무사히 막을 내렸다.

서울 코엑스 3층에서 다양한 기술들을 만날 수 있었다.

또한 다양한 볼거리와 요즘 기술 동향을 파악할 수 있었다. .

우리도 조그마한 부스에 기술들을 전시하였다. 

하지만 다리가 너무 아팠다. 오랜만에 구두를 신고 하루 종일 서 있느라.. 정말 누가 발바닥을 찌지는 줄 알았다.ㅠ 









728x90
반응형

'Study > Technology Issues' 카테고리의 다른 글

CSA(Cloud Security Alliance) Publication 이란?  (0) 2023.03.23
Web 3.0 IPFS 분산파일 시스템  (0) 2023.03.17
Web 3.0 기술 중 IPFS 기술에 대해  (0) 2023.03.17
ChatGPT 아시나요?  (0) 2022.12.12
qmil 설치방법  (0) 2019.09.03

댓글()