Минимальная жизнеспособная безопасность — начните с малого, затем итерируйте с Дэвидом Меламедом

Дэвид Меламед — один из пяти соучредителей и технический директор компании Jit, платформы непрерывной безопасности для разработчиков. Он родился во Франции и имеет степень доктора философии в области биоинформатики.

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

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

Ссылки:

Jit (Twitter | LinkedIn | Facebook)
Дэвид Меламед: Twitter | LinkedIn | GitHub

У вас есть идеи о том, как мы можем сделать наше шоу лучше? Или вы хотели бы стать гостем одного из предстоящих эпизодов? Свяжитесь с нашей командой #devrel по адресу devrel@newrelic.com. Мы будем рады услышать от вас любые вопросы, любопытства и/или отзывы в надежде сделать наше шоу лучшим из возможных!

Следите за нами: @PolyglotShow

Минимальная жизнеспособная безопасность — начните с малого, затем итерируйте с Дэвидом Меламедом

Полиглот

1x инициализация… ×

Транскрипт:

Кирк Хейнс: Добро пожаловать на «Полиглот». Меня зовут Кирк Хейнс. Вы можете найти меня под ником @wyhaines в Twitter и практически везде в интернете. И сегодня я хотел бы поприветствовать моего гостя, Дэвида Меламеда.

Дэвид Меламед: Спасибо, Кирк, за приглашение. Итак, всем привет. Я Дэвид Меламед. Я один из пяти сооснователей и технический директор Jit, платформы непрерывной безопасности для разработчиков. И немного обо мне: я родился во Франции почти 44 года назад. Я имею степень доктора философии в области биоинформатики. Я переехал из Франции в Израиль около 13 лет назад, женился, и теперь у меня четверо детей.

Профессионально я работаю последние 20 лет в качестве full-stack инженера, технического директора, технического евангелиста, в основном в облачных технологиях и, в частности, в облачной безопасности для нескольких ведущих компаний, таких как MyHeritage, CloudLock, которая затем была приобретена Cisco, где я возглавлял некоторые стратегические и технологические проекты для офиса технического директора подразделения облачной безопасности. Я обычно очень любознателен и люблю делиться своими знаниями, а также расширять возможности других людей. И в рамках этого я участвовал в нескольких местных сообществах вокруг Python и AWS в течение последних нескольких лет.

Фантастика. Почему бы нам не начать с самого начала? Мы дойдем до того, чем вы сейчас занимаетесь, а затем немного расскажем о том, чем вы сейчас занимаетесь. Итак, вы родились во Франции и получили докторскую степень по биоинформатике, верно?

Дэвид: Да, именно так.

Кирк: Как вы перешли от докторской степени по биоинформатике к работе в качестве full-stack инженера? Каким был этот переход?

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

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

Постепенно я перешел от работы в MyHeritage только в качестве back-end инженера, а затем, через несколько лет, перешел на свою вторую должность в Израиле, и в течение нескольких месяцев я был техническим директором. И там, поскольку я был техническим директором, мне пришлось иметь дело с множеством разных вещей, поэтому, естественно, я стал full-stack. Вот так я и стал full-stack с самого начала работы в области биологии.

Кирк: [смеется] Мне нравится, что развитие карьеры иногда происходит именно так. Мы просто идем в таких направлениях, что если бы вы могли вернуться в прошлое и спросить нас тогда, мы бы понятия не имели, где окажемся.

Дэвид: Да, определенно. Мне нравится делать так много всего, например, писать книгу или сочинять стихи. Так что я мог заниматься самыми разными вещами, а в итоге стал инженером-программистом.

Кирк: Это фантастика. Я предполагаю, что, когда мы разговаривали ранее, вы упомянули Python. Я предполагаю, что из-за биоинформатики и того факта, что Python много используется в этой области, Python, вероятно, был одним из ваших ранних влиятельных языков, которые вы используете.

Дэвид: На самом деле, совсем нет. Когда я работал в области биоинформатики для получения докторской степени, я написал программу для визуализации ДНК в 3D, и я написал ее на Visual C++. А вообще-то большинство популярных инструментов в биоинформатике в то время были на Perl, поэтому я выучил Perl. Потом я работал в компании, которая использовала Java, поэтому я выучил Java. Затем я переехал в Израиль и попал в компанию MyHeritage, а они использовали PHP, поэтому я выучил PHP. А потом, будучи техническим директором, они использовали Node, и я выучил Node.

Кирк: [смеется].

Дэвид: Потом я пришел в сферу кибербезопасности в CloudLock, и там был Python, так что я выучил Python. Так что каждый раз я узнавал что-то новое, и это было очень интересно.

Кирк: Да, это потрясающе. Мне всегда нравится, когда я разговариваю с людьми, и они упоминают Perl, потому что Perl был первым языком, который я, можно сказать, знал очень, очень хорошо. Есть много языков, с которыми ты знакомишься в своей карьере. Но Perl был первым, когда я понял, что знаю этот язык вдоль и поперек. И все же я не думаю, что написал хоть строчку на Perl за 10 лет.

Дэвид: Да, я тоже. [смеется].

Кирк: Да, это увлекательно.

Дэвид: То же самое с PHP. Каждый раз, когда я переходил на другой язык, я просто что-то писал. Я узнавал что-то новое, а потом двигался дальше.

Кирк: Да, так веселее. Итак, чем вы занимаетесь сейчас?

Дэвид: Сейчас я являюсь соучредителем и техническим директором небольшого стартапа на ранней стадии под названием Jit. Мы пытаемся решить очень сложную проблему, которая в наши дни кажется все более и более важной, а именно — как обеспечить безопасность облачных приложений. И это трудная проблема, потому что инженеры по безопасности — это не те, кто владеет облачными приложениями. Это инженеры. Это инженеры, которые живут в инженерных организациях.

Но проблема в том, что если вы посмотрите на современный мир и тенденции, то увидите такие вещи, как микросервисы и CI/CD. Все эти различные тенденции говорят в пользу того, чтобы убедиться, что вы можете быстро доставлять продукты, и у вас может быть небольшой цикл обратной связи с рынком. И проблема в том, что если вы посмотрите на инженеров, они скажут: «Да, мы владеем нашими микросервисами. Мы их создаем, мы их тестируем, мы их развертываем. Мы поддерживаем их». Но они не делают одного — не обеспечивают их безопасность, потому что в большинстве случаев ответственность за безопасность лежит не на инженерных организациях.

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

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

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

Кирк: В этом есть смысл. Вы упомянули в нашем разговоре о концепции минимальной жизнеспособной безопасности. Я правильно понял? MVS?

Дэвид: Да.

Кирк: Что это такое?

Дэвид: Дело в том, что если сейчас вы просите инженеров и инженерную организацию взять на себя риск и заниматься безопасностью, то им нужно преодолеть несколько проблем. Одна из проблем заключается в том, что они не знают, что делать. Если вы спросите у любого стартапа на начальном этапе, безопасен ли его продукт или что они сделали в плане безопасности, каждый ответит вам что-то свое, потому что не существует реального стандарта. Поэтому первое, что им нужно знать, — это что делать.

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

Концепция MVS минимальной жизнеспособной безопасности заключается в следующем: вы не хотите брать целый список требований безопасности, который можно найти в Интернете. На самом деле это первое, что сделает любой технический директор. Они поищут в Интернете какой-нибудь контрольный список требований безопасности. Что мне нужно сделать? Большинство списков действительно большие, и это пугает.

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

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

И вот что мы делаем, например, в компании Jit: мы хотим предоставить список минимальных требований. Таким образом, план безопасности — это список требований, составленный с учетом особенностей вашей среды. И по сути, вы начинаете с него. Это не конец пути; это только начало, потому что безопасность — это всегда путь. У нее нет конца. Вы всегда можете добавить что-то еще. И поэтому вы каждый раз делаете итерации и добавляете что-то еще. Но главное — делать это непрерывно.

Как и в agile, у вас есть CI. У вас есть непрерывная интеграция. Каждый раз, когда вы добавляете что-то новое, вы не хотите ломать другие вещи, поэтому у вас есть тесты на вменяемость, регрессионные тесты, то же самое здесь. Каждый раз, когда вы добавляете новую систему безопасности, вы все равно хотите иметь возможность контролировать то, что вы уже сделали. Вот почему мы говорим здесь о концепции непрерывной безопасности, которая является еще одной парадигмой поверх CI/CD, о которой мы можем подумать в CS.

Я могу привести несколько примеров минимальных вещей, потому что есть много разных интересных элементов или средств контроля, о которых мы можем поговорить. И есть разные области, которые здесь задействованы, когда вы говорите о безопасности продукта. Например, вы можете, конечно, взглянуть на код. В коде можно посмотреть на такие вещи, как уязвимости в коде, и добавить статический анализ с помощью сканера SAST. Это должно быть очень просто.

Вы также можете посмотреть на зависимости и добавить некоторый контроль SCA. То есть вы проверяете зависимости, чтобы увидеть, есть ли там какие-то уязвимости, о которых известно. И мы сейчас много говорим об этом в СМИ в связи с Log4j и всеми другими уязвимостями, потому что это критическая проблема.

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

Вам также необходимо позаботиться о времени выполнения вашего приложения. И здесь есть кое-что минимальное, что вы можете сделать. Например, если вы используете AWS, вам нужно убедиться, что, конечно же, вы используете MFA для своих учетных записей. Вам нужно убедиться, что вы не используете корневые учетные записи. Есть много вещей, которые действительно минимальны. И если вы проведете некоторую автоматизацию, это можно сделать простым нажатием кнопки. Но помимо этого, я буду говорить здесь только о технических средствах контроля.

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

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

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

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

Кирк: Так значит, Джит… вы фокусируетесь на том, чтобы помочь людям понять, каков этот список для их конкретной среды? Это то, чем вы занимаетесь или?

Дэвид: Да, именно так. В Jit мы считаем, что завтра каждое облачное приложение должно начинаться с обеспечения безопасности с нуля. И проблема в том, что это сложно, потому что нужно сделать очень много вещей. Поэтому мы хотим предоставить список минимальных вещей, которые вам нужно сделать, когда вы начинаете свой проект. А затем мы можем поговорить о более продвинутых планах в будущем, например, я не знаю, вы хотите обеспечить соответствие, потому что у вас есть бизнес-потребность в этом. Это уже потом.

Но принцип заключается в том, что вы начнете с чего-то минимального. Список будет полностью автоматизирован, так что, применив свой список, вы сможете увидеть все интеграции в вашей среде, будь то в CI/CD, будь то в вашем runtime, в вашем pipeline, во всех различных областях, которые имеют отношение к безопасности вашего продукта. И конечно, мы также предоставляем этот список, и он отображается в виде кода. Потому что мы считаем, что имеем дело с инженерами, и поэтому они, вероятно, захотят сделать некоторую настройку, потому что каждая организация работает по-своему. Поэтому процессы, которые у них есть, могут быть разными. Это одна из причин.

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

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

И поэтому мы хотим организовать все эти инструменты таким образом, чтобы у вас был список с различными вариантами управления. Если вы хотите что-то бесплатное… и мы считаем, что MVS должен быть бесплатным для всех, потому что это наше видение. Мы верим в мир, где каждое облачное приложение должно быть защищено с нуля, и именно поэтому MVS должен быть бесплатным. Но затем у вас появляются более продвинутые бизнес-потребности. И для этого, как нам кажется, обязательно потребуется интеграция с каким-то коммерческим продуктом.

Кирк: Хорошо, тогда позвольте мне задать вам гипотетический вопрос, потому что мне интересно, как это работает на самом деле. Допустим, у меня есть приложение, приложение Ruby on Rails с очень стандартной типичной архитектурой Ruby on Rails. Мы размещаемся на AWS, и у нас есть база данных Postgres. И, возможно, есть пара других сервисов, которые мы используем для получения данных. Но ничего особо сложного, потому что это довольно молодое приложение. И мы хотим начать концентрироваться на безопасности и применить к нему принцип MVS. Так мы приходим к Jit. И что мы делаем? Как это работает?

Дэвид: По сути, сейчас вы просто устанавливаете приложение GitHub. И как только вы устанавливаете приложение, вы автоматически получаете базовый план, то есть план MVS. И мы добавляем этот план MVS в ваш GitHub в определенное репо в вашей организации GitHub, чтобы вы могли видеть план в виде кода. Вы также можете увидеть его в пользовательском интерфейсе и просмотреть план. На самом деле план сгруппирован по различным уровням. Так, у вас есть код, есть архитектура, инфраструктура, сторонние сервисы. У вас есть список различных слоев.

И в каждом слое у вас есть список элементов, вещей, которые будет делать Jit. И поэтому, просто зафиксировав план, как вы бы сделали это для какого-нибудь кода, который вы фиксируете в Git, вы фиксируете план. План отправляется в вашу организацию GitHub. Кроме того, мы автоматически добавляем интеграции. Скажем, например, интеграции с кодом, который будет находиться в CI. И вот что мы делаем: мы генерируем из плана список… допустим, в CI вы используете GitHub Actions. Затем мы генерируем файл рабочего процесса GitHub, который будет включать все различные инструменты, которые, по нашему мнению, вам нужны, поскольку каждый из них связан с отдельным пунктом плана.

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

В других областях, например, у нас есть интеграция с AWS. Там у нас есть роль доверенного лица вашей организации. По сути, вы предоставляете нам доступ на чтение к AWS, и мы можем убедиться, что у вас включен CloudTrail. Мы можем сделать это либо в виде кода, если вы используете Infrastructure as Code, например Terraform, либо проверить это в вашей среде. Допустим, одним из основных действий, которые вам необходимо выполнить при использовании AWS, является, например, проверка наличия журналов аудита с помощью CloudTrail.

Поэтому мы покажем вам список тестов, которые мы выполняем. Здесь будет тест на то, что у вас включен CloudTrail, и вы его провалите, потому что у вас не включен CloudTrail. А затем вы можете исправить ситуацию, просто нажав на кнопку. Вы сможете включить CloudTrail либо путем добавления PR в ваш код, либо, если у нас есть доступ на запись, мы сможем запустить его через API.

Кирк: Очень аккуратно. Итак, план MVS, вы сказали, что он выражен в коде. В чем он реализован?

Дэвид: Здесь интересно, потому что у нас было много мыслей, как выразить что-то подобное, потому что это будет похоже на список. Но с другой стороны, мы хотели действительно мощный язык. Поэтому мы выбрали то, что на самом деле не является кодом; на самом деле это декларативный код. То есть это фактически куча файлов YAML, которые определяют различные концепции. Итак, у нас есть концепция элементов, и элементы могут быть частью нескольких планов. То есть у вас может быть план, который является MVS. Но тот же элемент может быть частью более крупного плана, например SOC 2.

И поэтому, если вы фактически реализуете и применяете план MVS, и, допустим, добавляете план реагирования на инциденты в свою среду, вы автоматически продвигаетесь и к SOC 2, потому что это тот же самый пункт, который присутствует и во втором плане. Таким образом, мы можем представить себе сетку, когда у вас есть все различные планы с отображением всех элементов управления из разных планов один на другой. И по сути, когда вы применяете некоторые элементы в плане A, вы также добиваетесь прогресса в планах B, C и D, потому что они используют одни и те же элементы.

Кирк: Итак, у вас есть куча файлов YAML, которые определяют части вашего плана. А затем у вас есть некий центральный механизм, который интерпретирует эти YAML-файлы и применяет планы. Правильно ли я понимаю?

Дэвид: Да. Итак, план сейчас выражен в YAML. И для каждого элемента у вас есть список рабочих процессов, которые выполняются. И эти рабочие процессы могут выполняться в различных, скажем так, бегунах. Один запуск может быть GitHub Action. Один запуск может быть нашим облаком, другой — вашим облаком. Таким образом, механизм фактически преобразует план в нечто исполняемое, что может быть запущено в любой из сред, о которых я говорил.

Кирк: Это довольно изящная реализация. Так является ли она языково-агностической в том смысле, что мы говорили о Ruby on Rails. Но что если у меня есть приложение на Elixir, или приложение на Crystal, или что-то в этом роде? Являетесь ли вы языково-агностичным, или есть определенные языковые семейства, которые вы поддерживаете лучше, чем другие?

Дэвид: На данный момент у нас уже есть несколько элементов управления, и некоторые из них не зависят от языка. Например, у нас есть элемент управления, который проверяет наличие секретов, где вы используете открытый исходный код, отличный открытый исходный код Gitleaks. Он полностью адаптирован к языку, потому что ищет определенные шаблоны, определенные шаблоны в коде, такие как RegEX для секретов, так что он полностью адаптирован к языку.

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

Кирк: Мне вот что интересно. Мы говорили о том, что люди должны делать. И я знаю из своего опыта работы с Rails-приложениями, что иногда очень легко, как вы уже говорили, упустить из виду простые вещи, просто потому что вы сосредоточены на функциях, которые должны быть предоставлены, и сроках. И вы не обращаете внимания даже на иногда очень простые аспекты безопасности. Поэтому мне просто интересно, каковы несколько действительно распространенных вещей, о которых люди забывают даже подумать при создании своих приложений, но которые очень легко исправить? Есть ли какие-то закономерности, которые вы заметили?

Дэвид: Да. Например, я могу сказать вам это на примере пользователей, которые уже используют нашу платформу. Мы получили несколько замечательных отзывов от людей, которые говорили нам: «Вы спасли нас, потому что нам удалось выявить секреты, которые были в PR». Сегодня очень легко забыть некоторые секреты в коде, потому что вы тестируете что-то локально и недостаточно просматриваете свой код во время фиксации.

Но дело в том, что как только вы фиксируете это на GitHub, в принципе, даже если это частный репозиторий, он уже не совсем безопасен, потому что вы не знаете, кто может его прочитать. И поэтому, даже если мы обнаружили, вам все равно нужно его переработать. Так что это действительно базовая вещь. И один из способов — добавить что-то в ваш CI. Другой способ — добавить какой-нибудь pre-commit hook в вашу собственную машину, чтобы на самом деле вы проверяли свой код перед фиксацией, чтобы не допустить утечки секретов.

Еще одна вещь, если мы все время говорим о секретах, заключается в том, что многие люди работают с ключами AWS. И правильный или лучший способ работы с ними — использовать такие инструменты, как AWS Vault, чтобы ваши ключи никогда не хранились на вашем собственном ноутбуке в открытом виде, потому что в противном случае они могут быть зафиксированы по умолчанию. Или, если вы не обратили внимания, например, вы можете иметь это в некоторых переменных окружения, и по ошибке вы зафиксируете свой файл. С файлом профиля Bash это может произойти. Поэтому я бы сказал, что secret — это очень, очень базовая вещь, которую нужно проверять.

Кроме того, если вы работаете в среде AWS, я знаю много людей, которые все еще используют и злоупотребляют учетной записью root. И мы в Jit потратили довольно много времени, пытаясь найти лучший способ работы с защитой и загрузкой учетных записей AWS. И сейчас я как раз пишу об этом блог. Поэтому я хочу поделиться тем, как сделать первый шаг создания учетной записи, которая будет безопасной, чтобы, например, вам не пришлось определять пользователей в нескольких местах. Допустим, у вас несколько учетных записей. Вы не должны определять пользователя несколькими способами, потому что этим вы увеличиваете площадь атаки.

Поэтому мы создали отдельную учетную запись AWS для пользователей, и они фактически меняются ролями. И это все — код с использованием Terraform. Они будут фактически переключать роли между различными учетными записями, чтобы получить доступ. И здесь вы можете обеспечить безопасность, потому что вы можете, например, применить MFA. Так вы убедитесь, что если кому-то удастся завладеть учетными данными пользователей, он не сможет попасть, например, в продакшн, потому что он не сможет так легко обойти MFA.

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

Вот почему мы также хотим донести это до каждого. Вот почему мы считаем, что MVS должен быть бесплатным, потому что очень легко упустить эти вещи из виду. И не так уж сложно применять их, если они автоматизированы, конечно, и именно поэтому мы упорно работаем над автоматизацией.

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

Я знаю, что (не буду называть имен), но была одна компания, с которой я работал, где было именно то, о чем вы сказали: все вещи AWS находились под пользователем root. Не было никаких профилей IAM для различных пользователей. И это была очень простая вещь, которая помогла все заблокировать, потому что когда вы увольняете людей, которые покидают компанию, если у них есть доступ к этому корневому пользователю, у вас есть огромная уязвимость, и ее легко упустить.

Дэвид: Да, именно так. Вот почему, например, в наших компаниях мы реализовали это так: у нас все в виде кода в Terraform, и в основном добавление и удаление пользователя — это вопрос одной строки в коде Terraform. И поэтому я могу предоставить доступ к другой среде, добавив одну строчку. Я могу удалить пользователя, просто удалив две строки в коде.

Кирк: Это фантастика.

Дэвид: И еще одна вещь: я определил в каждой среде роль, которая имеет доступ только для чтения, и роль, которая имеет доступ для записи, потому что это одно и то же; вы хотите применить наименее привилегированный доступ. Итак, с одной стороны, вы хотите, чтобы ваши разработчики могли иногда отлаживать вещи в производстве. Другого способа сделать это нет. Но с другой стороны, вы определенно не хотите предоставлять им доступ на запись из-за возможных последствий. Итак, основное, что вам нужно сделать, это иметь две роли. Я бы начал именно с этого.

Но затем вы можете подумать: «Хорошо, может быть, я могу ограничить доступ только для чтения только теми службами, которые должен проверять разработчик. Например, если ему нужны журналы, я дам вам доступ к журналам. И я не дам ему доступ к коду Lambda или, я не знаю, к любым другим сервисам, потому что ему это не нужно. Вот так постепенно вы реализуете наименее привилегированный доступ. Вы также можете сделать это по-другому, например, проверив CloudTrail и посмотрев, какие именно API и сервисы используются. И таким образом вы можете разделить все роли.

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

И вы также хотите предоставить ему доступ к данным точно в срок. Это то, что мы называем JIT, just in time. Потому что то, что убивает разработчиков, — это переключение контекста. И поэтому каждый раз, когда вы можете дать ему информацию о проблемах безопасности, когда он на самом деле работает над этим, тогда он обязательно исправит это. Но если ошибка уже в производстве, и ему нужно ее исправить, то это влечет за собой огромные расходы.

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

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

Дэвид: Конечно. Прежде всего, мне было очень приятно. Было очень, очень приятно, что вы пригласили меня в свою передачу, и мне очень понравился наш разговор. Для всех, кому интересно узнать больше о концепции MVS, которую мы фактически взяли из концепции MVP, минимального жизнеспособного продукта в мире продуктов, для всех, кто хочет узнать больше об этом и заинтересован даже в тестировании нашей платформы, которая в настоящее время находится в раннем релизе, просто посетите наш сайт jit.io. Там есть простая кнопка «Начать работу», и тогда вы сможете запустить и протестировать нашу платформу.

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

И поэтому я хотел бы пожелать всем иметь лучший, безопасный продукт. Если я могу кому-то помочь или вы хотите найти меня, вы можете найти меня на GitHub, dvdmelamed. Это очень просто, потому что я большой поклонник фильмов, так что это dvdmelamed, то же самое в Twitter. Вы также можете найти меня на LinkedIn. В ближайший месяц я буду участвовать во многих конференциях. И поэтому я буду рад пообщаться со всеми, кто интересуется вопросами безопасности. И еще раз спасибо за приглашение на ваше шоу.

Кирк: Спасибо, что присоединились ко мне. Это была замечательная беседа. И спасибо всем остальным за то, что слушаете нас. Вы можете найти нас в Twitter @PolyglotShow. А это Кирк Хейнс из New Relic. Спасибо, и мы снова увидимся с вами на следующей неделе.

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *