Продолжение первой части:
Во второй части обзора будет приведена информация об SQL Databases, физической безопасности, средствах обеспечения безопасности, которыми может воспользоваться клиент, сертификации платформы и рекомендациях по обеспечению безопасности.
Безопасность SQL Databases
SQL Azure Databases использует стандартный протокол SQL Server Tabular Data Stream (TDS), но разрешены исключительно шифрованные коммуникации. В SQL Server 2008 было введено новое средство: прозрачное шифрование данных (transparent data encryption, TDE), позволяющее полностью шифровать данные с минимальными усилиями. Однако на данный момент SQL Azure Databases не поддерживает шифрование на уровне базы данных. Следует заметить, что в настоящее время SQL Azure Databases доступен только через TCP-соединения и только через порт 1433. Поэтому необходимо учитывать возможности шифрования ADO.NET и сертификаты. А, например, свойства соединения Encrypt = True и TrustServerCertificate = False обеспечат защиту передаваемых данных и помогут предотвратить атаки «человек посередине» (man-in-the-middle). Второе средство защиты SQL Database Azure, и, в общем-то, основное — брандмауэр SQL Azure Databases, которым изначально блокируется весь доступ к серверу SQL Azure Databases. Попытки подключения до соответствующей настройки будут безуспешны. Для начала работы с сервером SQL Azure Databases нужно зайти на портал SQL Azure и определить настройки брандмауэра для доступа к вашему серверу. Брандмауэром SQL Azure можно управлять через портал SQL Azure или напрямую в главной базе данных с помощью хранимых процедур, таких как sp_set_firewall_rule и sp_delete_firewall_rule.
Как и в любой реализации SQL Server, управление пользовательскими учетными записями — еще один аспект, который нужно жестко контролировать. Благодаря этим средствам SQL Azure является высокозащищенной управляемой платформой для приложений в облаке.
Между SQL Server и SQL Azure Databases в контексте безопасности существует список различий:
Вы можете также использовать Windows Azure Trust Services для шифрования данных.
Физическая безопасность
Услуги Windows Azure предоставляются пользователям через глобальную сеть датацентров, разработанных с учетом необходимости работать круглосуточно, на каждом из которых используются различные средства для защиты системы от сбоев питания, физического вторжения и обрывов сетевого подключения. Эти географические распределенные центры обработки данных соответствуют индустриальным стандартам обеспечения физической безопасности и надежности. Корпорация Microsoft не делегирует задачи по обслуживанию собственных датацентров другим компаниям, и сотрудники Microsoft полностью осуществляют управление, мониторинг и администрирование датацентрами корпорации.
Microsoft использует механизмы доступа с высокой степенью безопасности, доступные только ограниченному числу сотрудников, которые регулярно изменяют пароли доступа администратора. Доступ к датацентрам и полномочия открывать билеты доступа к центрам обработки данных контролируются директором по работе сети в соответствии с локальными рекомендациями по обеспечению безопасности датацентра.
Security Development Lifecycle
Windows Azure полностью соответствует требованиям, предъявляемым к безопасности цикла разработки (Security Development Lifecycle, SDL) корпорации Microsoft, который был признан как модель безопасности программного обеспечения достаточно высокого уровня.
Безопасность, обеспечиваемая клиентом
Разумеется, что, несмотря на все колоссальные усилия корпорации Microsoft по обеспечению всех аспектов безопасности данных клиентов и собственных датацентров, клиент должен принимать в этом процессе непосредственное участие. В данный момент существует множество методов, средств и инструментов обеспечения безопасности на стороне клиента, в том числе и сертифицированных программных средств корпорации Microsoft. В этом разделе приведен краткий список сертифицированных Microsoft средств, которые можно и нужно использовать для обеспечения безопасности.
Windows Azure Virtual Network
Виртуальная сеть Windows Azure позволяет настроить виртуальные частные сети (VPN) в Windows Azure и управлять ими, а также безопасно интегрировать их с локальной инфраструктурой. С помощью виртуальной сети можно расширить локальную инфраструктуру в облако, управляя при этом сетевой топологией, в том числе конфигурацией IP-адресов, таблиц маршрутизации и политиками безопасности. К типичным сценариям использования Windows Azure Virtual Network можно отнести безопасное расширение датацентра в облако ( традиционные VPN-сети для безопасного масштабирования датацентра. Виртуальная сеть использует протокол IPSEC для установки защищенного подключения между корпоративным VPN-шлюзом и Windows Azure. За пределами VPN-шлюза можно добавить любое число компьютеров) и разработку гибридных сценариев (интеграцию облачного приложения с локальной инфраструктурой любого типа, включая Unix-системы).
Windows Azure Connect
Служба Windows Azure Connect обеспечивает интеграцию Windows Azure и локальными ресурсами на основе агентов Azure Connect, в том числе серверами баз данных и контроллерами домена. Windows Azure предоставляет полный контроль для создания виртуальных сетей и настройки IP-адресов в облаке.
К частым сценариям использования Windows Azure Connect можно отнести: создание распределенных приложений (безопасное подключение к локальной инфраструктуре без лишнего кода, например, облачное приложение может обращаться к локальному серверу БД SQL Server или Active Directory), отладку приложений (удаленно, с использованием прямого подключения между локальным компьютером разработчика и приложениями, размещенными на платформе Windows Azure, что позволяет устранять ошибки и выполнять отладку с помощью инструментов, используемых для локальных приложений).
ServiceBus
Сервис Service Bus предоставляет возможность безопасной передачи данных и обеспечения relay, что позволяет строить распределенные и слабосвязанные приложения в облаке. С помощью Service Bus можно легко обезопасить каналы связи от локальных клиентов к облаку, либо внутри облака.
Сертификация
В обзоре безопасности любой платформы, которой активно пользуются, нельзя обойти стороной вопрос сертификации платформы различными организациями. Windows Azure имеет набор сертификатов от ведущих лидеров индустрии в области сертификации.
Общая информация о сертификации приведена в табл. 1.
Таблица 1. Сертификация функциональности Windows Azure
ISO 27001
Платформа Windows Azure была сертифицирована как удовлетворяющая ISO 27001 British Standards Institute (BSI).На момент написания статьи по ISO сертифицированы следующие компоненты платформы:
• Compute (включая Web и Worker роли)
• Storage (включая сервисы хранилищ блобов, очередей и таблиц)
• Virtual Machine (включая VM-роль)
• Virtual Network (включая Traffic Manager и Connect)
При этом отдел Microsoft Global Foundation Services имеет отдельную сертификацию по ISO 27001 для тех датацентров, в которых размещается платформа Windows Azure.
FISMA
Платформа Windows Azure была сертифицирована как удовлетворяющая условиям для эксплуатации для федеральных органов власти по Federal Information Security Management Act (FISMA).
Рекомендации по обеспечению безопасности
Используйте последние обновления безопасности
Хорошей практикой является использование свойства osFamily и osVersion в ServiceConfiguration.cscfg – указывая последнюю доступную версию ОС, вы гарантируете наличие последних автоматически устанавливаемых обновлений, в том числе безопасности.
Ограничьте максимальный объем хранящихся логов и следите за их содержанием
Одним из типов атак является DoS, когда хранилище логов может разрастаться до больших размеров, что может привести к отказу каких-либо сервисов. Ограничьте максимальный объем хранящихся логов. Кроме этого, внимательно отслеживайте их содержание и ни в коем случае не логируйте критичные и важные данные. Регулярно анализируйте получаемые логи, так как не все атаки могут быть быстрыми – многие из них могут растягиваться на долгое время, и в этом случае главной задачей является их своевременное обнаружение. Регулярно делайте резервное копирование, чтобы злоумышленник даже при успешном взломе не смог затереть следы своей деятельности.
Избегайте проверок важных данных на стороне клиента
Не реализовывайте механизмов проверки важных данных на стороне клиента, перенося серьезную бизнес-логику на сервер.
Используйте сложные пароли
Лучшая практика обеспечения безопасности – используйте сложные пароли и меняйте их по прошествии определённого промежутка времени. Простой пароль может быть взломан с помощью различных атак типа брутфорса либо атаки с использованием словаря.
Аккуратно используйте модель пула подключений
Несмотря на преимущество оптимизации производительности, предоставляемое использованием пула подключений, это может иметь потенциальную опасность – может возникнуть ситуация, когда подключением пользователя-администратора воспользуется пользователь с меньшими правами.
Не храните учетные и просто данные в небезопасном месте
Не забывайте шифровать учетные данные, а также использовать такие механизмы аутентификации и авторизации, которые передают учетные данные простым текстом. Если вы используете аутентификацию на основе утверждений – используйте для передачи токенов безопасности зашифрованный канал. Зашифрованный канал также может помочь против различных атак, например, session replay, когда злоумышленник перехватывает сообщения и повторяет их в целях ввода в заблуждение системы. Не передавайте данные в запросах HTTP GET, так как это может привести к ситуации, когда простым копированием строки запроса могут быть скопированы важные данные, кроме этого строки запросов HTTP GET сохраняются в истории браузера, на прокси-серверах и в логах веб-сервера.
Разработайте систему авторизации на основе ролевой модели
Разработайте систему, в которой будет несколько типов ролей – например, роль или аккаунт с наименьшими привилегиями и администратор, а также принципы разграничения доступа к различным областям вашего сервиса. Не давайте слишком большому количеству человек права администратора. Не делайте из администратора суперпользователя.
Планируйте тип аутентификации заранее
В зависимости от имеющихся задач можно использовать различные типы аутентификации с различными источниками данных. Например, в том случае, если вы имеет уже готовое ASP.NET приложение, которое использует Membership и в ваши задачи не входит обязательно использование сложной авторизации, то есть не использующей ничего больше простых логинов, паролей и ролевой модели, хорошим решением может быть использование аутентификации на основе форм с источником данных в сервисах хранилища Windows Azure. Если же вам необходима более сложная бизнес-логика, вы можете использовать как источник данных SQL Azure Databases либо, если ваш сценарий подразумевает сложные интеграционные задачи по использованию локальной Active Directory из облачного приложения, вашим выбором может стать использование аутентификации на основе утверждений и AD FS 2.0. В случае необходимости использования федеративной аутентификации замечательным вариантом является Windows Azure Active Directory (Access Control Service), за которым можно будет объединить набор как публичных (Facebook, Live Id, …), так и приватных (Active Directory) провайдеров идентификации.
Группируйте части приложения
Размещение максимального числа компонентов вашего сервиса в пределах одного датацентра либо региона поможет повысить как его производительность и скорость работы, так и степень безопасности за счёт минимизации передаваемого за пределы датацентра трафика.
Обрабатывайте исключения правильно
К потенциальным уязвимостям, порой весьма серьёзным, может приводить слишком избыточный текст выброшенного исключения. Не включайте в текст исключения информацию, которая может рассказать о вашей системе то, что вы не хотели бы, чтобы знал посторонний человек.
Проверяйте то, что даёт вам пользователь
Никогда не доверяйте тому, что будет вводить клиент, без нескольких слоёв проверки этого. Проверяйте всё, иначе возможен взлом системы с использованием различных атак, например, SQL Injection. Централизуйте механизмы проверки, разработав специальную библиотеку. Никогда сразу не создавайте контейнеры или другие сущности в хранилище Windows Azure, используя информацию, предоставленную пользователем – сначала проверяйте её или преобразовывайте.
Частичное доверие
По умолчанию роли, разворачиваемые на платформу Windows Azure, работают с использованием полного доверия, что позволяет вызывать не-.NET код или использовать соответствующие библиотеки, требующие администраторских прав, что может вызвать определенную вероятность нарушения безопасности. Использование частичного доверия позволяет хотя бы ненамного ограничить возможность того, что взломщик будет иметь полный доступ к системе – например, с частичным доверием взломщик не сможет модифицировать файлы. Определить явным образом частичное доверие можно в файле определения сервиса (ServiceDefinition.cscfg), используя атрибут enableNativeCodeExecution, определив его значение как false.
Управляйте ключами грамотно
Принцип прост – нельзя использовать ключи, предоставляемые Windows Azure, как ключи для шифрования данных. Кроме этого, что относится к управлению ключами, отличным решением будет смена ключей в определенном временном промежутке. Например, так как на каждый аккаунт хранилища выделяется два 256-битным ключа, в один момент времени можно использовать один, в другой – второй, по прошествию же какого-то времени можно сгенерировать новый основной ключ и перейти на его использование.
Активно используйте SharedAccessSignatures и разрешения
Активно используйте Shared Access Signatures и различные разрешения для того, чтобы ограничить доступ к аккаунту хранилища.После 7 июня 2012 года Shared Access Signature стали доступны для всех сервисов хранилища (до 7 июня они были доступны только для блобов).
Активно используйте сервисы шифрования
Не забывайте о существовании различных реализаций криптографических стандартов (Cryptographic Service Providers), алгоритмах и др. В том числе реализаций Microsoft:
Microsoft Base Cryptographic Provider
Microsoft Strong Cryptographic Provider
Microsoft Enhanced Cryptographic Provider
Microsoft AES Cryptographic Provider
Microsoft DSS Cryptographic Provider
Microsoft Base DSS and Diffie-Hellman Cryptographic Provider
Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider
Microsoft DSS and Diffie-Hellman/Schannel Cryptographic Provider
Microsoft RSA/Schannel Cryptographic Provider
Microsoft RSA Signature Cryptographic Provider
Избегайте разработки собственных механизмов шифрования – скорее всего, они будут менее совершенны, нежели принятые стандартные механизмы.
Не шифруйте и не хэшируйте Partition Keys для сущностей в хранилище Windows Azure.
При использовании однонаправленных хэш-функций используйте SHA с минимальной длиной ключа в 256 бит, при использовании симметричного шифрования используйте AES с минимальной длиной ключа в 256 бит, при использовании ассиметричного шифрования используйте RSA с минимальной длиной ключа в 2048 бит.
Заключение
Резюмируя, можно объединить основные пункты, касающиеся безопасности, в один короткий список:
• Аутентификация с SSLдля всего внутреннего трафика – все коммуникации внутри платформы защищаются SSL.
• Сертификаты и приватные ключи устанавливаются отдельно от кода, использующего их.
• Принцип наименьших привилегий для программного обеспечения – пользователи не имеют администраторских привилегий на виртуальных машинах, программное обеспечение же, разворачиваемое на платформе, работает под непривилегированным аккаунтом.
• Ключи данных – все аккаунты хранилища имеют по двум секретным ключам, используемому для контроля доступа к данным.
• Изолированность гипервизора, корневой ОС, гостевой ОС и Fabric Controller – корневые ОС изолированы от гостевых, гостевые изолированы друг от друга, всё управляется гипервизором и корневой ОС. Доступ к Fabric Controller строжайше ограничен.
• Фильтры пакетов. Гипервизор и корневая ОС используют фильтры пакетов для ограничения возможности спуфинга трафика от недоверенных виртуальных машин. Также ограничен broadcast-трафик.
• VLAN – все критичные компоненты расположены в собственных изолированных VLAN-ах.
• При выполнении клиентом операции удаления данных система гарантирует, что их невозможно восстановить.
Как и на любой новой платформе, даже с учётом всех внесённых изменений, средства защиты и шифрования в Windows Azure еще находятся в стадии развития и требуют постоянной доработки, однако это абсолютно нормальная ситуация – регулярно появляются новые угрозы, которые необходимо учитывать при планировании развития платформы.
Полезные ссылки
Windows Azure Trust Center — www.windowsazure.com/en-us/support/trust-center
Во второй части обзора будет приведена информация об SQL Databases, физической безопасности, средствах обеспечения безопасности, которыми может воспользоваться клиент, сертификации платформы и рекомендациях по обеспечению безопасности.
Безопасность SQL Databases
SQL Azure Databases использует стандартный протокол SQL Server Tabular Data Stream (TDS), но разрешены исключительно шифрованные коммуникации. В SQL Server 2008 было введено новое средство: прозрачное шифрование данных (transparent data encryption, TDE), позволяющее полностью шифровать данные с минимальными усилиями. Однако на данный момент SQL Azure Databases не поддерживает шифрование на уровне базы данных. Следует заметить, что в настоящее время SQL Azure Databases доступен только через TCP-соединения и только через порт 1433. Поэтому необходимо учитывать возможности шифрования ADO.NET и сертификаты. А, например, свойства соединения Encrypt = True и TrustServerCertificate = False обеспечат защиту передаваемых данных и помогут предотвратить атаки «человек посередине» (man-in-the-middle). Второе средство защиты SQL Database Azure, и, в общем-то, основное — брандмауэр SQL Azure Databases, которым изначально блокируется весь доступ к серверу SQL Azure Databases. Попытки подключения до соответствующей настройки будут безуспешны. Для начала работы с сервером SQL Azure Databases нужно зайти на портал SQL Azure и определить настройки брандмауэра для доступа к вашему серверу. Брандмауэром SQL Azure можно управлять через портал SQL Azure или напрямую в главной базе данных с помощью хранимых процедур, таких как sp_set_firewall_rule и sp_delete_firewall_rule.
Как и в любой реализации SQL Server, управление пользовательскими учетными записями — еще один аспект, который нужно жестко контролировать. Благодаря этим средствам SQL Azure является высокозащищенной управляемой платформой для приложений в облаке.
Между SQL Server и SQL Azure Databases в контексте безопасности существует список различий:
- Microsoft SQL Server поддерживает аутентификацию Windows Integrated с использованием параметров доступа из Active Directory; SQL Azure Databases поддерживает только SQL Server Authentication.
- Microsoft SQL Server и SQL Azure Databases используют одну модель авторизации на основе пользователей и ролей, создаваемых в каждой базе данных и связываемых с логинами пользователей.
- Microsoft SQL Server имеет стандартные роли уровня сервера такие как serveradmin, securityadmin и dbcreator. SQL Azure Databases этих ролей нет. Вместо этого в SQL Azure Databases есть роль loginmanager (создание логинов) и dbmanager (создание и управление базами данных). Эти роли могут быть привязаны к пользователям в базе данных master.
- Доступ к SQL Server и SQL Azure Databases происходит по протоколу уровня приложения Tabular Data Stream (TDS), защищённому протоколом SSL, через порт TCP/1433. Использование SSL опционально для Microsoft SQL Server и обязательно для SQL Azure Databases.
- В SQL Server контроль доступа на основе IP должен быть осуществлен на уровне хоста или сети, с использованием брандмауэров. В SQL Azure Databases есть встроенный брандмауэр, ограничивающий весь доступ к серверу SQL Azure Databases до определения клиентов компьютеров, имеющих право доступа. Брандмауэр выдает доступ, основываясь на IP-адресе каждого запроса.
- SQL Server предоставляет шифрование в режиме реального времени всех хранящихся данных на страничном уровне с использованием функциональности Transparent Data Encryption (TDE). Подобное шифрование не поддерживается в SQL Azure Databases.
Вы можете также использовать Windows Azure Trust Services для шифрования данных.
Физическая безопасность
Услуги Windows Azure предоставляются пользователям через глобальную сеть датацентров, разработанных с учетом необходимости работать круглосуточно, на каждом из которых используются различные средства для защиты системы от сбоев питания, физического вторжения и обрывов сетевого подключения. Эти географические распределенные центры обработки данных соответствуют индустриальным стандартам обеспечения физической безопасности и надежности. Корпорация Microsoft не делегирует задачи по обслуживанию собственных датацентров другим компаниям, и сотрудники Microsoft полностью осуществляют управление, мониторинг и администрирование датацентрами корпорации.
Microsoft использует механизмы доступа с высокой степенью безопасности, доступные только ограниченному числу сотрудников, которые регулярно изменяют пароли доступа администратора. Доступ к датацентрам и полномочия открывать билеты доступа к центрам обработки данных контролируются директором по работе сети в соответствии с локальными рекомендациями по обеспечению безопасности датацентра.
Security Development Lifecycle
Windows Azure полностью соответствует требованиям, предъявляемым к безопасности цикла разработки (Security Development Lifecycle, SDL) корпорации Microsoft, который был признан как модель безопасности программного обеспечения достаточно высокого уровня.
Безопасность, обеспечиваемая клиентом
Разумеется, что, несмотря на все колоссальные усилия корпорации Microsoft по обеспечению всех аспектов безопасности данных клиентов и собственных датацентров, клиент должен принимать в этом процессе непосредственное участие. В данный момент существует множество методов, средств и инструментов обеспечения безопасности на стороне клиента, в том числе и сертифицированных программных средств корпорации Microsoft. В этом разделе приведен краткий список сертифицированных Microsoft средств, которые можно и нужно использовать для обеспечения безопасности.
Windows Azure Virtual Network
Виртуальная сеть Windows Azure позволяет настроить виртуальные частные сети (VPN) в Windows Azure и управлять ими, а также безопасно интегрировать их с локальной инфраструктурой. С помощью виртуальной сети можно расширить локальную инфраструктуру в облако, управляя при этом сетевой топологией, в том числе конфигурацией IP-адресов, таблиц маршрутизации и политиками безопасности. К типичным сценариям использования Windows Azure Virtual Network можно отнести безопасное расширение датацентра в облако ( традиционные VPN-сети для безопасного масштабирования датацентра. Виртуальная сеть использует протокол IPSEC для установки защищенного подключения между корпоративным VPN-шлюзом и Windows Azure. За пределами VPN-шлюза можно добавить любое число компьютеров) и разработку гибридных сценариев (интеграцию облачного приложения с локальной инфраструктурой любого типа, включая Unix-системы).
Windows Azure Connect
Служба Windows Azure Connect обеспечивает интеграцию Windows Azure и локальными ресурсами на основе агентов Azure Connect, в том числе серверами баз данных и контроллерами домена. Windows Azure предоставляет полный контроль для создания виртуальных сетей и настройки IP-адресов в облаке.
К частым сценариям использования Windows Azure Connect можно отнести: создание распределенных приложений (безопасное подключение к локальной инфраструктуре без лишнего кода, например, облачное приложение может обращаться к локальному серверу БД SQL Server или Active Directory), отладку приложений (удаленно, с использованием прямого подключения между локальным компьютером разработчика и приложениями, размещенными на платформе Windows Azure, что позволяет устранять ошибки и выполнять отладку с помощью инструментов, используемых для локальных приложений).
ServiceBus
Сервис Service Bus предоставляет возможность безопасной передачи данных и обеспечения relay, что позволяет строить распределенные и слабосвязанные приложения в облаке. С помощью Service Bus можно легко обезопасить каналы связи от локальных клиентов к облаку, либо внутри облака.
Сертификация
В обзоре безопасности любой платформы, которой активно пользуются, нельзя обойти стороной вопрос сертификации платформы различными организациями. Windows Azure имеет набор сертификатов от ведущих лидеров индустрии в области сертификации.
 |
Общая информация о сертификации приведена в табл. 1.
Таблица 1. Сертификация функциональности Windows Azure
| Функциональность Windows Azure | ISO 27001 | SSAE 16 ISAE 3402 | EU Model Clauses | HIPAA BAA |
| Web Sites | ||||
| Virtual Machines | X | X | X | X |
| Cloud Services | X | X | X | X |
| Storage (Tables, Blobs, Queues) | X | X | X | X |
| SQL Database | ||||
| Caching | ||||
| Content Delivery Network (CDN) | ||||
| Networking | X | X | X | X |
| Windows Azure Active Directory | ||||
| Service Bus | ||||
| Media Services |
ISO 27001
Платформа Windows Azure была сертифицирована как удовлетворяющая ISO 27001 British Standards Institute (BSI).На момент написания статьи по ISO сертифицированы следующие компоненты платформы:
• Compute (включая Web и Worker роли)
• Storage (включая сервисы хранилищ блобов, очередей и таблиц)
• Virtual Machine (включая VM-роль)
• Virtual Network (включая Traffic Manager и Connect)
При этом отдел Microsoft Global Foundation Services имеет отдельную сертификацию по ISO 27001 для тех датацентров, в которых размещается платформа Windows Azure.
FISMA
Платформа Windows Azure была сертифицирована как удовлетворяющая условиям для эксплуатации для федеральных органов власти по Federal Information Security Management Act (FISMA).
Рекомендации по обеспечению безопасности
Используйте последние обновления безопасности
Хорошей практикой является использование свойства osFamily и osVersion в ServiceConfiguration.cscfg – указывая последнюю доступную версию ОС, вы гарантируете наличие последних автоматически устанавливаемых обновлений, в том числе безопасности.
Ограничьте максимальный объем хранящихся логов и следите за их содержанием
Одним из типов атак является DoS, когда хранилище логов может разрастаться до больших размеров, что может привести к отказу каких-либо сервисов. Ограничьте максимальный объем хранящихся логов. Кроме этого, внимательно отслеживайте их содержание и ни в коем случае не логируйте критичные и важные данные. Регулярно анализируйте получаемые логи, так как не все атаки могут быть быстрыми – многие из них могут растягиваться на долгое время, и в этом случае главной задачей является их своевременное обнаружение. Регулярно делайте резервное копирование, чтобы злоумышленник даже при успешном взломе не смог затереть следы своей деятельности.
Избегайте проверок важных данных на стороне клиента
Не реализовывайте механизмов проверки важных данных на стороне клиента, перенося серьезную бизнес-логику на сервер.
Используйте сложные пароли
Лучшая практика обеспечения безопасности – используйте сложные пароли и меняйте их по прошествии определённого промежутка времени. Простой пароль может быть взломан с помощью различных атак типа брутфорса либо атаки с использованием словаря.
Аккуратно используйте модель пула подключений
Несмотря на преимущество оптимизации производительности, предоставляемое использованием пула подключений, это может иметь потенциальную опасность – может возникнуть ситуация, когда подключением пользователя-администратора воспользуется пользователь с меньшими правами.
Не храните учетные и просто данные в небезопасном месте
Не забывайте шифровать учетные данные, а также использовать такие механизмы аутентификации и авторизации, которые передают учетные данные простым текстом. Если вы используете аутентификацию на основе утверждений – используйте для передачи токенов безопасности зашифрованный канал. Зашифрованный канал также может помочь против различных атак, например, session replay, когда злоумышленник перехватывает сообщения и повторяет их в целях ввода в заблуждение системы. Не передавайте данные в запросах HTTP GET, так как это может привести к ситуации, когда простым копированием строки запроса могут быть скопированы важные данные, кроме этого строки запросов HTTP GET сохраняются в истории браузера, на прокси-серверах и в логах веб-сервера.
Разработайте систему авторизации на основе ролевой модели
Разработайте систему, в которой будет несколько типов ролей – например, роль или аккаунт с наименьшими привилегиями и администратор, а также принципы разграничения доступа к различным областям вашего сервиса. Не давайте слишком большому количеству человек права администратора. Не делайте из администратора суперпользователя.
Планируйте тип аутентификации заранее
В зависимости от имеющихся задач можно использовать различные типы аутентификации с различными источниками данных. Например, в том случае, если вы имеет уже готовое ASP.NET приложение, которое использует Membership и в ваши задачи не входит обязательно использование сложной авторизации, то есть не использующей ничего больше простых логинов, паролей и ролевой модели, хорошим решением может быть использование аутентификации на основе форм с источником данных в сервисах хранилища Windows Azure. Если же вам необходима более сложная бизнес-логика, вы можете использовать как источник данных SQL Azure Databases либо, если ваш сценарий подразумевает сложные интеграционные задачи по использованию локальной Active Directory из облачного приложения, вашим выбором может стать использование аутентификации на основе утверждений и AD FS 2.0. В случае необходимости использования федеративной аутентификации замечательным вариантом является Windows Azure Active Directory (Access Control Service), за которым можно будет объединить набор как публичных (Facebook, Live Id, …), так и приватных (Active Directory) провайдеров идентификации.
Группируйте части приложения
Размещение максимального числа компонентов вашего сервиса в пределах одного датацентра либо региона поможет повысить как его производительность и скорость работы, так и степень безопасности за счёт минимизации передаваемого за пределы датацентра трафика.
Обрабатывайте исключения правильно
К потенциальным уязвимостям, порой весьма серьёзным, может приводить слишком избыточный текст выброшенного исключения. Не включайте в текст исключения информацию, которая может рассказать о вашей системе то, что вы не хотели бы, чтобы знал посторонний человек.
Проверяйте то, что даёт вам пользователь
Никогда не доверяйте тому, что будет вводить клиент, без нескольких слоёв проверки этого. Проверяйте всё, иначе возможен взлом системы с использованием различных атак, например, SQL Injection. Централизуйте механизмы проверки, разработав специальную библиотеку. Никогда сразу не создавайте контейнеры или другие сущности в хранилище Windows Azure, используя информацию, предоставленную пользователем – сначала проверяйте её или преобразовывайте.
Частичное доверие
По умолчанию роли, разворачиваемые на платформу Windows Azure, работают с использованием полного доверия, что позволяет вызывать не-.NET код или использовать соответствующие библиотеки, требующие администраторских прав, что может вызвать определенную вероятность нарушения безопасности. Использование частичного доверия позволяет хотя бы ненамного ограничить возможность того, что взломщик будет иметь полный доступ к системе – например, с частичным доверием взломщик не сможет модифицировать файлы. Определить явным образом частичное доверие можно в файле определения сервиса (ServiceDefinition.cscfg), используя атрибут enableNativeCodeExecution, определив его значение как false.
Управляйте ключами грамотно
Принцип прост – нельзя использовать ключи, предоставляемые Windows Azure, как ключи для шифрования данных. Кроме этого, что относится к управлению ключами, отличным решением будет смена ключей в определенном временном промежутке. Например, так как на каждый аккаунт хранилища выделяется два 256-битным ключа, в один момент времени можно использовать один, в другой – второй, по прошествию же какого-то времени можно сгенерировать новый основной ключ и перейти на его использование.
Активно используйте SharedAccessSignatures и разрешения
Активно используйте Shared Access Signatures и различные разрешения для того, чтобы ограничить доступ к аккаунту хранилища.После 7 июня 2012 года Shared Access Signature стали доступны для всех сервисов хранилища (до 7 июня они были доступны только для блобов).
Активно используйте сервисы шифрования
Не забывайте о существовании различных реализаций криптографических стандартов (Cryptographic Service Providers), алгоритмах и др. В том числе реализаций Microsoft:
Microsoft Base Cryptographic Provider
Microsoft Strong Cryptographic Provider
Microsoft Enhanced Cryptographic Provider
Microsoft AES Cryptographic Provider
Microsoft DSS Cryptographic Provider
Microsoft Base DSS and Diffie-Hellman Cryptographic Provider
Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider
Microsoft DSS and Diffie-Hellman/Schannel Cryptographic Provider
Microsoft RSA/Schannel Cryptographic Provider
Microsoft RSA Signature Cryptographic Provider
Избегайте разработки собственных механизмов шифрования – скорее всего, они будут менее совершенны, нежели принятые стандартные механизмы.
Не шифруйте и не хэшируйте Partition Keys для сущностей в хранилище Windows Azure.
При использовании однонаправленных хэш-функций используйте SHA с минимальной длиной ключа в 256 бит, при использовании симметричного шифрования используйте AES с минимальной длиной ключа в 256 бит, при использовании ассиметричного шифрования используйте RSA с минимальной длиной ключа в 2048 бит.
Заключение
Резюмируя, можно объединить основные пункты, касающиеся безопасности, в один короткий список:
• Аутентификация с SSLдля всего внутреннего трафика – все коммуникации внутри платформы защищаются SSL.
• Сертификаты и приватные ключи устанавливаются отдельно от кода, использующего их.
• Принцип наименьших привилегий для программного обеспечения – пользователи не имеют администраторских привилегий на виртуальных машинах, программное обеспечение же, разворачиваемое на платформе, работает под непривилегированным аккаунтом.
• Ключи данных – все аккаунты хранилища имеют по двум секретным ключам, используемому для контроля доступа к данным.
• Изолированность гипервизора, корневой ОС, гостевой ОС и Fabric Controller – корневые ОС изолированы от гостевых, гостевые изолированы друг от друга, всё управляется гипервизором и корневой ОС. Доступ к Fabric Controller строжайше ограничен.
• Фильтры пакетов. Гипервизор и корневая ОС используют фильтры пакетов для ограничения возможности спуфинга трафика от недоверенных виртуальных машин. Также ограничен broadcast-трафик.
• VLAN – все критичные компоненты расположены в собственных изолированных VLAN-ах.
• При выполнении клиентом операции удаления данных система гарантирует, что их невозможно восстановить.
Как и на любой новой платформе, даже с учётом всех внесённых изменений, средства защиты и шифрования в Windows Azure еще находятся в стадии развития и требуют постоянной доработки, однако это абсолютно нормальная ситуация – регулярно появляются новые угрозы, которые необходимо учитывать при планировании развития платформы.
Полезные ссылки
Windows Azure Trust Center — www.windowsazure.com/en-us/support/trust-center
