Содержание статьи
Из читателей в руководители
Так сложилось, что в моей жизни именно журнал «Хакер» определил то, чем я профессионально занимаюсь до сих пор. Поэтому у меня к «Хакеру» особенные чувства. Однажды, в конце девяностых, в нем вышла статья моего приятеля. Я купил журнал, прочитал и подумал: «О, как круто!» С того момента я стал покупать и читать его регулярно.
Потом мы тусили на одном канале вместе с ребятами из «Хакера» в русском DalNet (популярный в нулевых российский агрегатор IRC-сетей. — Прим. ред.), где были редакторы «Хакера», в том числе Сергей «SINtez» Покровский. Как-то он спросил: «А чего ты пишешь на какой-то сайт? Давай пиши в наш журнал!» Вот так я и стал автором. Я не был редактором никакой из рубрик, но тогда формировался костяк из регулярно пишущих людей (так называемая X-crew), и какое-то время я в эту команду входил.
Знаете ведь как бывает? Ты постоянно изучаешь какие-то вещи, тебе нравится, и ты хочешь ими поделиться — получается статья. Я писал на протяжении как минимум четырех лет. Потом я окончил институт, меня начала затягивать работа... Кажется, в 2006 году я перестал регулярно писать в «Хакер».
Яндекс как большой дом
В Яндексе я дома, со всеми вытекающими отсюда плюсами. Сейчас много людей уезжает из России на Запад, но мало кто остается там на всю жизнь. Едут в основном молодые, которые хотят посмотреть, попробовать. Некоторые, конечно, остаются, но отъезд на Запад для айтишников, мне кажется, не самоцель. Это не переезд в Америку или в Лондон. Они едут в крупные ИТ-компании, уезжают работать в Facebook, Google, Amazon. Все остальное — это уже побочные эффекты. Кстати, айтишнику проще адаптироваться на Западе. Просто потому, что многие айтишники сидят за компом по 24 часа в сутки, игнорируют языковые и культурные барьеры, так как особо не ведут социальную жизнь.
Яндекс — это место, где ты можешь получить все то же самое в плане интересных задач, работы с данными и сложными системами, попробовать машинное обучение и другие современные технологии. При этом ты остаешься у себя дома, в России.
Не числом, а умением!
Яндекс обычно сравнивают с такими компаниями, как Facebook и Google, но у нас есть важное отличие. Яндекс — это компания, которая со штатом в 5–7 тысяч человек делает такие же штуки, как западные компании со штатом в 50–60 тысяч человек. Это результат хорошего образования, более глубокого знания математики и подготовки более универсальных программистов.
То есть надо понимать, с кем и в каких условиях нам приходится конкурировать. У Facebook, например, по сути, есть один сервис и одно приложение. Нет «зоопарка» и сложной экосистемы, но людей задействовано раз в десять больше, чем в Яндексе.
Это момент, который, мне кажется, многие не понимают. Здесь, в Яндексе, гораздо выше концентрация всего: больше разных задач и свободы для программиста. Ты можешь сам выбирать, чем заниматься.
В Google, например, уже сложились рабочие процессы, и тебя берут на конкретную очень узкую задачу. Условно говоря, представь, что ты занимаешься перекладыванием бумажек с места на место. Тебе за это платят деньги, у тебя есть свой KPI, и тебя постоянно оценивают: как ты эту бумажку берешь, как несешь, как ровно ты ее положил. Тебе нельзя выходить за рамки своих задач. При этом скреплять листы степлером — это уже работа другого человека. В Яндексе нас мало, а проектов очень много, поэтому у тебя невероятная (по американским меркам) свобода как у технаря.
Есть еще китайцы, Baidu. Но там другая история. Как говорили про Baidu одни мои западные товарищи, которые с ними работали: «Мы пришли, и нам дали в помощь небольшой отдел из 500 человек». То есть они берут числом.
Технократия и единство технологий
Яндекс привлекает еще и тем, что в нем отсутствует излишняя бюрократия. Как следствие — есть возможность быстрее и эффективнее обучаться. Если сравнивать с теми же Google и Facebook, я бы сказал, что у нас бюрократии нет вообще. Есть технократия, и вот в чем она проявляется. Яндекс все-таки сильно вырос. Когда людей становится больше, то контролировать их собственную эффективность сложнее. Но порог входа у нас высокий, и мы понимаем, что если кто-то неэффективно работает, то это, скорей всего, потому, что к человеку не нашли подхода, а не потому, что он неспособен. Нужно задать ему правильный вектор развития.
Вектор — это тоже свобода, но не абсолютная, не мешающая другим. К примеру, ты не можешь сказать, что тебе не нравится принятая система обработки логов на внутреннем MapReduce и сейчас ты поднимешь свой Hadoop. Или ты не можешь писать на Rust просто потому, что так захотел. Хочешь использовать другие языки? Пожалуйста, но только в свободное время в качестве хобби. В основных же проектах есть перечень утвержденных языков программирования. Он нужен для того, чтобы проекты можно было поддерживать дальше, когда ими займутся другие программисты. По той же причине у нас есть единый репозиторий, и никто не хранит код «в тумбочке».
Здесь, в Яндексе, ты делаешь продукт, который потом кто-то должен поддерживать за тобой. Поэтому нужно соблюдать единство IT-технологий, использовать общую платформу развертывания и так далее. Словом, вместо бюрократии в Яндексе царит технократия.
DevOps
Есть модное слово, которого я стараюсь всячески избегать, — DevOps. Это принцип синергии разработчика, админа и даже безопасника. Сперва поясню, как работает классическая схема.
Разработчик написал и запустил сервис, через какое-то время сервис упал. Разработчик говорит администратору: «Ты не умеешь админить! Я пишу отличный код, а ты не умеешь его эксплуатировать!» Администратор спорит: «Нет, я нормальный админ. Это ты написал программу, которая течет и падает, ты не умеешь писать код!» Потом этот сервис ломают, и данные утекают. Админ и разработчик приходят к безопаснику и вместе начинают орать уже на него. Теперь это он виноват, потому что не умеет нормально проверять код на безопасность.
Так вот, культура DevOps отучает перекладывать вину на других. Пока для большинства это лишь модное слово, но мы в последние годы перестроились в этом направлении. Все мы в одной лодке. То есть ты написал код, ты же его и поддерживаешь. Есть инструменты безопасности, которые для тебя сделаны. Они интегрированы в твой процесс сборки и тестирования.
Безопасность в разработке
Ключевые слова для описания безопасности в такой компании, как Яндекс, — это автоматизация и интеграция. К примеру, ты написал приложение для Android и тебе нужно подписать приложение ключом разработчика. Ты не хранишь ключ у себя. У нас для этого есть сервис, который сделали безопасники. Он называется «Подписатор». Ты присылаешь туда свой файл, он подписывается и там же проходит основные проверки на безопасность. Обратно ты получаешь уже проверенный и подписанный файл.
Обычно как происходит? Программист пишет код, а потом в него добавляют средства безопасности. То есть ты пришел на работу, тебе сказали: вот твоя поляна — пиши. Ты ничего не знаешь о том, что делают безопасники, пока тебе не падает письмо: у тебя вот здесь в программе уязвимость, пожалуйста, исправь ее.
Мы стараемся, чтобы работа строилась по-другому, но старания начинаются не с момента написания кода, а еще раньше.
Как это выглядит в идеале. Ты пришел на работу, прошел собеседование (несколько секций с разными людьми). Одна из секций — собеседования про безопасность. Она не будет определяющей, потому что берут программиста, а не безопасника, но нам падает информация, что пришел такой-то человек и он плохо ответил на вопросы о безопасности. Это потенциальная проблема для нас в будущем. Тогда ему в рамках стандартного введения дают правила безопасной разработки, какие-то дополнительные кейсы, которые у нас есть. То есть мы начинаем думать о безопасности на уровне обучения, еще до того, как программист напишет свою первую строчку кода.
Дальнейшая безопасность затрагивает инструменты, которыми ты пользуешься. Есть такое популярное слово — SDL (Security Development Lifecycle), которое придумала и которому дала широкое распространение Microsoft. У нас взяты какие-то основные куски от SDL. Мы берем компоненты, которые важны для нас, и внедряем их.
К примеру, ты взял для своего проекта какую-то библиотеку, содержащую уязвимость. Тебя не бьют по рукам, но, когда ты закоммитишь свой код, сработают автоматические проверки. Они скажут, что ты притащил фигню, лучше возьми вот это. Финальный шаг — аудит твоего кода, причем аудит кода в рамках всего продукта. Его будет смотреть команда безопасников.
Security by default
Безопасникам знакома классическая концепция security by default. Согласно ей по умолчанию все запрещено, а ты запрашиваешь разрешение на каждое действие. Для меня в свое время стало открытием, что это не работает в компаниях типа Яндекса. Ты можешь двигаться быстро, только когда у тебя нет большого количества заборов на пути. Это была глобальная смена парадигмы.
Безопасность в таких IT-компаниях всегда реактивная. Ты изначально все можешь, но если зашел куда-то не туда, то тут же где-то загорается лампочка. К тебе приходит человек и спрашивает, зачем ты туда зашел. Также, когда ты получаешь доступ к каким-то ключевым местам, у тебя повторно запрашивают аутентификацию.
Когда мы начали общаться с нашими коллегами-визави из Facebook и Google, оказалось, что они делают так же. У них параллельно сложились аналогичные принципы. Никто ни на кого не смотрел, не учил. Совершенно независимо возникла одинаковая культура безопасности в разработке здесь и там.
Развитие способов защиты
Вообще, если говорить про тренды, сейчас отмирают и, думаю, окончательно отомрут многие вещи, которые нам до последнего казались классическими, обязательными. Например, DLP (защита от утечек). В современном мире использовать ее уже нереально. Внедряя DLP, ты обманываешь себя. Да, с ней можно поймать сотрудника, который по почте что-то не то отправил, но защититься от целенаправленного выноса данных с ней невозможно. Пока еще на DLP все смотрят как на обязательную вещь в компаниях «классического» уклада. Когда же интернет проникнет еще глубже, такие меры безопасности вчерашнего дня, как DLP, окончательно отомрут.
Вторая вещь, которая меняет парадигму безопасников, — это облачные инструменты. Причем сейчас я говорю не про структуры в облаке, все гораздо проще.
Как правило, проблемы случаются из-за каких-то мелких глупостей. Конечно, может, под тебя пятнадцать лет АНБ подкапывается, но гораздо раньше проблемы у тебя возникнут совсем по другой причине. Они произойдут, когда кто-то зальет коммерческую информацию куда-нибудь, просто не зная, что она сохраняется в облаке.
Поясню. Несколько лет назад мне нужен был «блокнот». Меня не устраивал стандартный маковский Notes, и я искал что-то получше. И я не смог найти в App Store ни одного необлачного! В том же Evernote, например, сначала была опция хранения в облаке как opt-in (ее надо было включить). Сейчас это опция opt-out (ее нужно найти и самому выключить). Причем она так запрятана, что 9 из 10 скачавших о ней просто не узнают. С точки зрения безопасности вот такие тривиальные вещи гораздо более рисковые.
Свежий пример: взлом Uber и то, как у них украли миллионы учетных записей. Там ведь никто не ломал сам сервис. Ситуация глупая: разработчик на GitHub держал свой не Uber’овский код, и у него в этом коде были зашиты логин и пароль. Просто лежали в public, а логин-пароль оказался такой же, как и от его учетной записи в компании. Uber в Amazon держал свои бэкапы, а этот логин и пароль подошли. Вот так «хакер» зашел, попробовал — подошло, и миллионы учеток утекли. В реальной жизни инциденты чаще происходят не из-за «продвинутых угроз», а по таким вот мелочам.
То есть уровни безопасности размылись. Подчас даже не отдаешь себе отчет: что ты используешь в облаке, что доступно снаружи. Современная работа идет в размытом периметре. Сам периметр — это уже вещь прошлого века. Сейчас у всех так. Если ты занимаешься бизнесом, который взлетает, то ты уже не покупаешь сервак и даже не арендуешь его. Вместо этого ты поднимаешь виртуалочку в Amazon и облачное хранилище. У тебя все там, а потом какой-нибудь сотрудник использует свой домашний пароль как рабочий и случается утечка.
Маркетинговый шум
Рынок средств безопасности устроен очень интересным образом. Есть производители решений по безопасности, и есть CISO, и у них возникает «круговая порука». Должен быть кто-то (обычно это вендор), кто скажет, что вот эта угроза — это новый тренд. Другие подхватят, что эта проблема важна и что от нее нужно покупать защиту. Соответственно, появятся люди, которые будут защищать компании, покупая эти продукты. Ведь если все вокруг кричат про APT (Advanced Persistent Threat), а у тебя нет продукта, который бы тебя защищал от APT, то ты выглядишь странно, и когда тебя сломают (по совершенно другой причине), то на тебя повесят всех собак — «не защищался от APT».
Этой связке «мир CISO — мир вендоров» надо постоянно придумывать новую фигню. DLP уже не покупают? Надо придумать новый buzz word! В последние годы появляются продукты, которые несут в себе слова machine learning, artificial intelligence и так далее. Это во многом пока ерунда. Если посмотреть на применение машинного обучения в безопасности, то пока оно там в зачаточном состоянии. Я думаю, что в будущем мы увидим продукты, которые уже не просто несут на себе маркетинговый значок, а действительно применяют алгоритм машинного обучения для обнаружения атак, для поиска каких-то аномалий. Но сейчас это не более чем новый тренд, так что сэкономьте деньги, купите более простые и насущные инструменты.
Я полагаю, что уже сейчас если ты берешь на работу человека, который должен отвечать за безопасность (менеджера, руководителя), то у него должен быть технический и практический background. Нужно достаточно разбираться в современных технологиях, чтобы хотя бы понимать, что bullshit, а что нет. Скоро окончательно вымоются теоретики, а практические знания станут еще более важны, но где их взять?
Обучение
Частные компании типа Яндекса вносят свой вклад в обучение, но тебе все равно дадут в них какую-то теорию, а практику ты сможешь получить только сам. С этой точки зрения ничего не поменялось с конца восьмидесятых годов. Для начинающего специалиста самое важное — это практика. Рецепт всегда будет одинаковым: просто брать и пробовать все руками. Ковырять, работать с этим фактически. Сидеть ночами, не спать, за компом портить глаза, потому что иначе профессионалом не стать.
Мы в Яндексе понимаем потребность молодежи в практической безопасности и поэтому открыли «Школу информационной безопасности», где делимся своим опытом.
Информационных ресурсов сейчас много, и это тоже проблема, внезапно. Глаза разбегаются, непонятно куда смотреть. Раньше были BBS’ки и OpenNET. В современном океане знаний качество материала сильно падает. Любой школьник может пройти, к примеру, на Хабр, написать там о чем-нибудь, и некому будет его поправить. Когда информации стало много, важно иметь какой-то фильтр, какое-то сообщество, которое гарантирует тебе качественный контент.
