Cloud check-list, or how the customer assessed us


    A large foreign company needed to call into our cloud due to the law on personal data. Since they themselves are engaged in auditing other companies, they approached the question habitually: they studied the market, made a list of requirements for the cloud, and began to check who corresponds to it and how.

    Transferred all systems: test environments, test + prod, preprod, all virtual machines, virtual servers plus all systems of virtual infrastructure. Even their support appeared in Russia. From us - only rent resources.

    They checked us notably, in scale: an almost complete audit of the data center. But they didn’t look at the hardware and technical characteristics mainly, but how the information security processes are built and how different SLAs are observed. From their point of view, it is the SLA stability processes that indicate the quality of the company's work. And we told them about each of the components in detail.

    I want to share a list of criteria for verification. Because at least some kind of methodology has appeared, because before that, few customers have approached the issue in such a systematic way.

    Common parameters


    The main requirements were about two dozen. Among them are such basic ones as placing the platform on two data centers, the availability of a console for resource management, the ability to work through the API, payment for services upon use with a granularity of not more than one hour, the availability of automation tools, for example, Terraform. Other requirements are not to say that we were very surprised, they are simply all the customers do not make. Among such requirements is the need to own the building in which the cloud data center operates.

    But here everything is clear in general. This customer apparently also read the history of the Russian collocation market. Or someone from their clients somewhere has already stuck abroad. Everything else is generally standard. The requirement of the data center in Moscow (this was also on the list) is for the opportunity to come to the admin and for the speed of requests for replication. The most important point after two data centers is detailed SLA metrics. As I said, it worried them most about each item.


    Staff Requirements


    It was one of the most difficult blocks, because the customer, having a huge experience in project activities (they have hundreds of industrial and retail customers around the world), shifted it to some extent on IT. In general, this is a sound approach, but the requirements turned out to be "heavy."

    That's what we were checked for:
    • The presence of three levels of technical support for the platform: the first line - solution of incidents at the platform level (HW, virtualization), the second line - solving problems in the customer's infrastructure located in the cloud platform (OS level, DBMS and other application software) cloud vendor platform developers and / or vendors to solve problems.
    • Mode 24x7x365 first-line technical support.
    • Mandatory knowledge of Russian and English languages ​​from specialists of all levels of support.
    • The possibility of placing applications for the incident that has occurred by e-mail or by calling technical support.
    • The ability to place requests for an incident on a call to technical support.
    • The response time of technical support specialists to an incident is from 10 to 15 minutes depending on the priority of the request (the supplier is obliged to record a detailed description of the priorities of incidents in the service contract).
    • The time to resolve an incident is from 90 to 240 minutes depending on the priority of the request (the supplier is obliged to record a detailed description of the priorities of incidents in the service contract).
    • The obligatory presence of a dedicated project team, which includes: account manager, project manager, technical architect, engineers.
    • The ability to use various means of communication between the supplier team and the customer team to more quickly resolve issues (for example, using Telegram, WhatsApp, etc.).
    • Fixing the list of the project team in a signed contract for cloud platform services. The list should include full name, contact mobile phone numbers, e-mail addresses of all customers and suppliers involved in the activity.
    Here one of the most important points for the customer was that it provided exactly three support lines. The first line is always there and at all, the second line of support is usually there, but the requirements for it are already quite blurry. But there is also a third one, which in fact cuts various chips. And nothing is given to outsourcing, as small providers sometimes do. The project involved only their employees. Not a service team is allocated for a large customer project, but a separate project team, and this is recorded in the documents.

    Dedicated project team - a separate important point. In a normal cloud service provider, this is usually included in the service in some form. But again, there is no explicit requirement for this, and there are no standards. In general, there are people who are directly involved in maintaining the client, there is a person who manages a specific project, there are engineers. It is expensive to allocate time for these people to the customer, but it is necessary, because in most cases the solution to rather complicated tasks is needed outside of “just hosting”. Or simple, but quickly and the first time. Therefore, these team members will be active 24x7, always in touch and ready to help. With any kind of communication that is convenient to the client. This is a service that is usually provided to "beloved" customers, but with us to everyone. And it is documented.

    On communication: it is very important to have personal phones in contacts in case of different emergency situations. In serious projects, communication goes through instant messengers to speed up (a couple of years ago it was not so, everyone communicated in the mail). The sales director gave a personal number, which does not turn off at night and on vacation - this is the norm. But not everyone can say this.

    Now a little more detail - about the requirements for individual subsystems and processes.

    Certification requirements


    Look
    • Система учёта потребляемых ресурсов должна соответствовать установленным требованиям «Правил применения автоматизированных систем расчётов, утв. Приказом Мининформсвязи России 02.07.2007 № 73».
    • Провайдер должен обладать актуальным сертификатом соответствия Систем управления информационной безопасности компании требованиям стандарта ISO/IEC 27001:2013 в отношении предоставления услуг аутсорсинга ЦОД и Виртуального ЦОД.
    • Наличие актуального сертификата на облачную платформу PCI DSS v3.2.
    • Аттестат соответствия PCI DSS 3.2 должен включать в себя ИТ-поддержку, физическую безопасность, безопасность системных сервисов, физическое оборудование, сети, хранилище.
    • Сертификаты ЦОД Tier III Design, ЦОД Tier III Facility, ЦОД Tier III Operational sustainability.


    There are no surprises: PCI DSS for financial data and T-III for three certificates. This is important for the business of the customer. For your company you need to make your own list of certification. But the first point deserves special attention. As it turned out, it was important for the customer that we provide a document that testifies to the competent work of our billing system. Fortunately for us, we just about a year before it was certified by the Ministry of Communications.

    Below is a list of requirements for the main elements of the cloud platform. Since we have previously worked quite closely with foreign customers, a similar list, but in a strongly abbreviated form, already existed. In one way or another, the information was specified in the SLA and other documents. At the request of a business consultant, we shoveled everything that we had, assembled and proapdatel. As a result, we received a fairly solid document that we can offer to other customers.
    So, what exactly is indicated in the checklists regarding the technical parameters of the platform.

    Computing resources


    Look
    • Выделение вычислительных ресурсов (виртуальные ядра, оперативная память) должно осуществляться гарантированным образом, исключающим возможность взаимного влияния виртуальных серверов заказчика, размещённых на одном физическом узле, друг на друга.
    • Облачная платформа должна предоставлять возможность изменения объёма вычислительных ресурсов без пересоздания ВМ.
    • Возможность гарантированного размещения ВМ на разных физических узлах.
    • Облачная платформа должна предоставлять выбор кластера (ДЦ) при запуске ВМ.



    Discs


    Look
    • Облачная платформа должна предоставлять возможность создания виртуальных дисков разной производительности (IOPS) через веб-интерфейс управления и API.
    • Облачная платформа должна предоставлять возможность изменения производительности дисков «на лету».
    • Дисковые ресурсы должны быть доступны с гарантиями производительности, измеряемой количеством IOPS на диск.
    • Гарантии производительности дисков должны распространяться до 100 000 IOPS.
    • Облачная платформа должна предоставлять возможность миграции данных между дисковыми ресурсами разной производительности «на лету» без остановки в предоставлении сервиса.



    Network


    Look
    • Облачная платформа должна позволять организовывать изолированные сетевые окружения, недоступные для других заказчиков облачной платформы.
    • Изолированные сетевые окружения облачной платформы должны позволять управлять сетевой адресацией и маршрутизацией ИТ-инфраструктуры заказчика.
    • Облачная платформа должна обладать функциональностью по подключению внешних выделенных каналов связи заказчиков.
    • Должно быть обеспечено назначение или удаление внешних IP-адресов виртуальным серверам при помощи облачной платформы.
    • Облачная платформа должна обеспечивать внешнее отказоустойчивое подключение на скорости не менее 40 Гбит/с.
    • Облачная платформа должна иметь встроенные DNS и DHCP-сервисы.
    • Облачная платформа должна обеспечивать IPSec VPN-соединения.
    • Облачная платформа должна обеспечивать отказоустойчивый доступ в сеть Интернет, не зависящий от провайдера, и агрегировать не менее четырёх провайдеров.
    • Пропускная способность между ВМ в пределах одного ЦОДа должна составлять не менее 10 Гбит/с.
    • L2-связность между виртуальными инфраструктурами, развёрнутыми в различных дата-центрах.


    Object Storage


    Look
    • Облачная платформа должна иметь файловый сервис, совместимый по программному интерфейсу с Amazon S3.
    • Объектное хранилище должно работать по протоколу, обеспечивающему возможность для хранения и получения любого объёма данных в любое время из любой точки сети Интернет.
    • Система хранения данных в целях отказоустойчивости должна быть распределена как минимум между двумя площадками исполнителя.
    • Система хранения должна иметь возможность расширяться по мере добавления файлов.
    • Объектное хранилище должно поддерживать версионирование.
    • Каждый объект в хранилище должен быть реплицирован между площадками исполнителя. В случае единичного отказа любого из компонент объектного хранилища не должно быть влияния на качество сервиса.
    • Возможность работы с хранилищем через HTTPS.
    • Поддержка access control list (ACL) и Policy.
    • Поддержка политики Object Lifecycle срока жизни объектов.
    • Возможность шифрования на стороне сервера Server side encryption.
    • Поддержка статических web-сайтов и пользовательских имен для web-сайтов типа mysite.ru
    • Уровень отказоустойчивости сервиса хранения — не ниже 99,99 %.


    IB


    Look
    • Должно быть обеспечено разделение информационной среды заказчика в рамках облачной платформы на несколько независимых виртуальных сетей.
    • Управление доступом к виртуальным сетям должно быть реализовано по различным портам и протоколам при помощи бесплатного встроенного межсетевого экрана.
    • Должно быть обеспечено объединение серверов виртуальной платформы в одну виртуальную частную сеть (VPN) с физическими или виртуальными серверами заказчика, расположенными на удалённой площадке или ЦОДе.
    • Доступ к функциям программного управления (API) облачной платформы должен быть предоставлен таким образом, чтобы не была допущена компрометация системы безопасности даже при использовании небезопасных транспортных протоколов.
    • Для доступа к функциям программного управления (API) облачной платформой должен применяться протокол HTTPS. Сертификаты должны быть подписаны доверенными центрами сертификатов.
    • Доступ к виртуальным Linux\UNIX-серверам должен осуществляться посредством протокола SSH с использованием беспарольной аутентификации по ключам. Виртуальная платформа должна предоставлять возможность управления ключами аутентификации (создание и удаление), а также обеспечивать доступный из ВМ механизм для доставки публичных ключей в ВМ в процессе её загрузки.
    • Организация защищённого доступа к серверам ИТ-системы должна осуществляться с использованием IPsec VPN-соединения.
    • В виртуальную платформу должен быть встроен межсетевой экран, настраиваемый отдельно для каждой виртуальной сети, а также для виртуальных сетей изолированных облачных окружений.
    • Наличие результатов теста на проникновение со сроком исполнения не более 1 года.


    Backup


    Look
    • Управление услугой резервного копирования должно производиться заказчиком самостоятельно через веб-интерфейс управления.
    • Через веб-интерфейс должна быть доступна функциональность по заданию расписания резервного копирования отдельных серверов, а также по их ручному резервному копированию и восстановлению.
    • Услуга по резервному копированию данных должна учитываться и оплачиваться по факту использования, а именно по Гигабайтам защищаемых данных в месяц.
    • Услуга по резервному копированию данных должна предоставлять возможность по резервному копированию распространённого корпоративного системного и прикладного ПО. Программные агенты, устанавливаемые на защищаемые серверы, должны быть бесплатными.
    • Управление резервным копированием — через веб-интерфейс и через программный агент.
    • Использование файлового эластичного S3-хранилища для хранения копий.
    • Использование дедупликации.


    Billing


    Look
    • В облачной платформе должно быть доступно логическое деление ВМ на группы с опцией раздельного биллинга.
    • Оплата только фактически занятого объёма.


    What ended


    The check was really exhausting for us, but thanks to it, we ourselves have learned a lot. For example, focusing on foreign colleagues, we worked through several procedures and put all the documents in order. Actually, we worked further for some time, and then we proposed a strategic partnership. Because this company also has many clients in Russia. Now this is all at the discussion stage, but the verification methodology has already appeared. Of course, the checklists do not give a complete picture of what the business consultants looked at and how, but I tried to unload the main thing that will allow you to build the verification methodology yourself. Here, of course, there is some slyness on my part, because we passed this test and won, that is, the checklists are almost fully applicable to our cloud. Because our platform corresponded to their large project. I hope that you use common sense and understand what your project needs from the platform, and accordingly change the requirements.

    If suddenly there were questions not for comments - my mail is NiVasilev@croc.ru
    Tags:

    Also popular now: