Директор AWS по информационной безопасности Стивен Шмидт рассказал порталу ComputerWeekly о том, как этот облачный гигант активно создает новые продукты и сервисы, сохраняя высокий уровень безопасности.

Аналитики часто отмечают, что темпы инноваций и разработки новых продуктов являются одним из главных конкурентных отличий Amazon Web Services (AWS). По данным 451 Research (2017 г.), облачный портфель продуктов и сервисов компании содержит больше 320 тыс. позиций, и 16% из них были созданы только за две недели ноября 2017 г.

При таких стремительных темпах выпуска продуктов возникает естественный вопрос, как AWS удается удерживать в фокусе внимания вопросы безопасности пользователей облака и учитывать их на всех этапах разработки всех продуктов, выносимых компанией на рынок?

Директор AWS по ИБ Стивен Шмидт говорит, что главным является умение разработчиков видеть процесс создания продукта с обратного конца, и первым, с чего они начинают свою работу, является одностраничный пресс-релиз с кратким и четким изложением того, что будет делать гипотетический сервис.

Причем это вовсе не имеет отношения к наметкам маркетинговых характеристик проектируемого сервиса или технологии. Смысл такого подхода заключается в том, чтобы сконцентрировать мысли команды разработчиков на предстоящей работе. «Суть в том, что если вы, как владелец сервиса, не можете сформулировать на одной странице и на общепонятном языке идею того, что вы собираетесь сделать, значит, вы сами не имеете четкого представления о том, над чем хотите работать», — считает Шмидт.

Добавим, что этот одностраничный документ должен создаваться в паре с сопроводительным перечнем часто задаваемых вопросов (FAQ) на тему безопасности будущего продукта, который должен предупредить любые потенциальные вопросы пользователей по безопасности их данных и аккаунтов. Это требование призвано обеспечить включение вопросов безопасности пользователей в проект создаваемого продукта с самых первых шагов.

Осмысление проекта

Пол Майзенер, вице-президент по инновациям Amazon, являющейся для AWS родительской компанией, считает, что подготовка пресс-релиза по еще не существующему продукту поддерживает у разработчиков чувство ответственности за конечный результат и будущий выход продукта на рынок. Он описывает этот подход как перевернутую во времени дорожную карту. Благодаря этому разработчики хорошо уясняют, что им надо сделать для пользователей, и мыслят процесс дальнейшей работы, ориентируясь на поставленную цель. При этом документ должен быть написан на понятном для пользователей языке без технического или внутрикорпоративного жаргона и рассказывать пользователям о том, что им близко.

Поскольку характеризуемая технология еще не появилась на свет, понятно, что пресс-релиз не подлежит непосредственному распространению. Однако он мобилизует творческие способности коллектива на предстоящую работу. Разработчики должны осознать, что задуманная цель потребует изобретательности, которая позволит сделать в будущем то, что еще нельзя сделать сегодня.

Команда на две пиццы

Численность и состав группы, которой поручается составить пресс-релиз, описывается правилом «команда на две пиццы», в соответствии с концепцией, придуманной CEO Amazon Джеффом Безосом. «Это должна быть разумно подобранная команда, не обязательно из одного подразделения компании, но в ней не должно быть больше людей, чем можно накормить двумя порциями большой американской пиццы», — говорит Майзенер.

Придерживаясь этого правила, организация не должна издавать излишних предписаний по численности группы разработчиков. Когда ее закрепляют приказом на все времена, это приводит к формальному подходу, который будет только мешать инновациям. «Например, мы решили собрать для концептуальной проработки проекта восемь человек, но через пару месяцев выяснилось, что дополнительно нужно привлечь специалиста по искусственному интеллекту, причем в организации такой человек есть и он готов присоединиться к команде. Неужели нам будет запрещено взять девятого человека?» — пояснил Майзенер.

«Правило двух пицц» также предотвращает создание слишком больших и неповоротливых групп. В последнем случае возникает риск разбиения коллектива на подгруппы, что усложнит коммуникации между отдельными членами команды.

Безопасность и контрольные точки

После создания группы по созданию концепции проекта и составления пресс-релиза может начинаться этап полноценной разработки продукта. По словам Шмидта, на разных стыках этого процесса должны существовать контрольные точки для тестирования надежности сервиса, его устойчивости к внешним факторам, а также оценки положения дел с его безопасностью.

Тестирование безопасности предполагает привлечение группы инженеров, испытывающих разные характеристики сервиса, связанные с управлением доступом, уровнями шифрования и гарантиями того, что проходящие через сервис данные будут защищены на всех отрезках пути.

Когда такие люди будут выделены, может начаться, как выражается Шмидт, «веселая часть» стресс-тестирования, а именно официальная процедура проверки безопасности приложения. Она сфокусирована на выявлении всех распространенных ошибок, встречающихся при разработке ПО, а также на проведении всех официально требуемых тестов.

Это процесс предполагает тестирование как положительных, так и отрицательных аспектов функциональности продукта. Для этого Amazon параллельно использует методологии черного и белого ящика. «В методе белого ящика группа тестирования имеет доступ к исходному коду и документации сервиса, так что у нее есть непосредственная возможность что-то преднамеренно нарушить, — рассказал Шмидт. — По методу черного ящика проверяется то, как сервис виден человеку со стороны и что получится при попытках извне нарушить его работу. Я бы сказал, что это очень своеобразная должностная обязанность, так как человеку платят зарплату за то, что оно что-то ломает. Задача весьма интересная, поскольку инженер должен войти в роль злоумышленника, представляя себе его менталитет и поведение. Он должен очень критически воспринимать работу сервисов и думать о том, какие увечья им может нанести лицо с преступными намерениями».

Подобное тестирование сервисов постоянно делается при сборке приложений для технического контроля качества. «Это происходит с самого начала процесса разработки, когда появляются первые строчки кода, вплоть до момента выпуска продукта и продолжается дальше, когда мы со временем перепроверяем наши сервисы», — добавил Шмидт.

Изнутри наружу

Многие из облачных сервисов и продуктов AWS оснащаются средствами и функционалом безопасности, которые вначале создавались лишь для внутреннего использования, но потом выпускаются во внешний мир. «Когда мы обсуждаем с пользователями наши подходы к определенным проблемам безопасности, они нас часто спрашивают, как AWS решает эти вопросы у себя дома», — говорит Шмидт.

Хотя многие из клиентов компании отвечают за работу сотен и тысяч систем, имущество AWS исчисляется в цифрах с гораздо большим числом нулей, и готовые стандартные инструменты безопасности тут далеко не всегда справляются со своими обязанностями. «В этой среде мы не можем использовать обычные средства безопасности, и нам приходится создавать свои инструменты, которые могут очень широко горизонтально масштабироваться. В результате у нас часто возникает соблазн взять то, что мы придумали для внутренних нужд, и ретранслировать эти наработки во внешний мир», — говорит Шмидт.

В качестве примера таких систем он ссылается на домашние дела компании по разработке продукта для машинного обучения, которые переросли в создание недавно запущенного сервиса AWS Macie. Этот сервис использует машинное обучение, например, для обнаружения, сортировки и классификации данных, хранимых в AWS Simple Storage Service (S3), тренируется на поиск информации, которая позволяет идентифицировать пользователей или корпоративную интеллектуальную собственность и, следовательно, может нуждаться в дополнительной защите.

Пользователям также предоставляется интерфейс, позволяющий отслеживать доступ к их данным или их перемещение, а Macie постоянно следит за моделями использования информации, чтобы фиксировать признаки, подтверждающие авторизованное использование или обработку данных.

При этом необходимо, чтобы пользователи обеспечили доступ Macie к содержимому их S3-бакетов и логов, и тогда примерно через две недели сервис начнет использовать эти данные в качестве критерия нормальных операций. «Сервис классифицирует контент, приобретая понимание происходящего в духе фраз „Я знаю, что здесь находится, я знаю, что это секретная информация, и я знаю, как люди это используют“, и через пару недель начинает выражать суждения и замечать вещи типа „Это способ использования отличается от обычного“», — говорит Шмидт.

После перехода от тренировки к полноценному функционированию система значительно освобождает пользователей от утомительной и повторяющейся работы по разбору информации, связанной с доступом и использованием корпоративных данных, хранимых в облаке.

Ценность человеческих суждений

Однако, говорит Шмидт, компания не ставит цели исключить людей из процесса, так как человек — самый ценный из ресурсов, который имеет любая группа по безопасности. В конечном счете только люди обладают способностью выносить обоснованные суждения о том, что выглядящая подозрительной активность создает для компании правдоподобный риск.

«Наша цель — разработать и внедрить инструменты, позволяющие людям мыслить, а не заниматься одной и той же ежедневной утомительной работой. Ценность машинного обучения заключается в том, что оно концентрирует людей на реально значимых вещах, отбраковывая то, что не имеет особого значения», — отметил он.

Например, Macie делает это, сигнализируя пользователям о присутствии наборов данных, которые могут содержать персонально идентифицируемую информацию, предоставляя списки всех людей, которые могут иметь к ней доступ, и отмечая, как они могли использовать это в прошлом.

«Macie может сообщить, что одна из серий доступов к данным является аномальной и выглядит отличной от других, и тогда люди могут поставить вопрос „Почему это происходило? Потому что пользователь занимался не совсем обычной работой или потому что имеет место что-то неожиданное?“, — рассказал Шмидт. — Возможно, сотрудник отдела продаж решил зачем-то загрузить большой объем исходного кода или разработчик ПО загружает в свою систему финансовые данные компании. Это те ситуации, когда Macie выдаст сигнал тревоги».

Помимо того, что клиенты AWS получают возможность использовать инструменты и технологии, созданные компанией для внутренних целей, ее непрекращающиеся поиски способов поддержания безопасности своего облака работают на благо всего Интернета. «Усовершенствования безопасности, внедряемые нами в интересах крупнейших заказчиков, — сказал Шмидт, — идут на пользу и студенту, выполняющему дома университетское задание через наш бесплатный сервис, так как в нем действуют точно те же функции безопасности. Этот процесс демократизации безопасности также реально оказывает сильную помощь Интернету в целом. Он идет на благо всем, но при этом стоит отметить малый и средний бизнес, у которого нет тех возможностей для инвестиций в безопасность, которые имеют крупные компании. Автоматизация и механизация безопасности позволяет небольшим организациям использовать плюсы тех же самых разработок, и наряду с этим они улучшают Интернет в интересах всего человечества».

Версия для печати (без изображений)