IT-стандарты *

Представьте типичный понедельник в отделе ИБ. Политики настроены, фильтрация работает, отчёты зеленые. А потом бухгалтер Марина открывает «счет от поставщика» из письма, пришедшего якобы с адреса директора — и все.

Технически все было сделано правильно. Но фильтрация не сработала — потому что строилась как технический барьер, а не как инструмент управления поведением пользователя. Разница между этими двумя подходами кроется в «все настроено» и «все работает».

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

Меня зовут Николай Куликов, руководитель группы сетевой безопасности департамента клиентского сервиса ГК «Солар». За 10 лет работы на стороне заказчика и в десятках пилотных инсталляций зрелой SWG‑системы Solar webProxy я выработал несколько принципов того, как строить контентную фильтрацию так, чтобы она учитывала не только трафик, но и поведение людей за экраном. В первой части — четыре практических сценария политик контентной фильтрации с учетом психологии пользователя на примере Solar webProxy.

Почему пользователь — главная уязвимость

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

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

За 15 лет WebPKI — экосистема доверия между сайтами и пользователями — сильно выросла. Появились технологии, которые делают это доверие более прозрачным и проверяемым, изменились подходы к управлению, а многие процессы стали автоматическими: выпуск и обновление сертификатов, публичный аудит через Certificate Transparency и другие механизмы. 

И, конечно, в истории WebPKI были серьёзные инциденты безопасности, которые показали: правила доверия должны быть публичными, прозрачными и проверяемыми.

Однако один вопрос не решается автоматически: кому браузер должен доверять и на каких условиях. Каждый вендор определяет это сам. Поэтому мы открываем Yandex Browser Root Certificate Program — публичную программу добавления корневых сертификатов в хранилище Яндекс Браузера. В ней описаны требования к участникам, аудит и понятная процедура подачи заявки.

Под катом рассказываем, какие требования нужно выполнить и как в Браузере устроены WebPKI и связанные с ними контроли безопасности.

Привет, Хабр! Я Владислав Тарасенко, системный аналитик в Т‑Банке. Расскажу о том, как проектировал онбординг для аналитиков Мобильного банка.

У нас был онбординг для новых аналитиков, и он не работал. Спустя месяц новички все еще не могли выполнить базовую задачу без помощи наставника. Мы решили подойти к онбордингу как к продукту: с метриками, жизненным циклом, MVP, UAT и поддержкой — и за 320 часов перепроектировали процесс с нуля.

Что изменилось: 

1. Сделали результат онбординга измеримым.
2. Сократили время адаптации: через неделю аналитик готов к работе. 
3. Улучшили автономность: 30% новичков теперь вообще не отвлекают наставников. 
4. Лояльность: оценка удовлетворенности выросла с 7,3 до 9,2 балла. 

Семь зон IT-риска, которые бизнес обычно игнорирует

В ноябре 2021 года я выступал на конференции про IT-риски. Я был краток: нужен был вид с высоты птичьего полёта.

Для бизнеса ИТ часто выглядит как поддержка, удобство и новые сервисы. А что, если система остановится? Что будет с бизнесом?

Я намеренно взял «обратную сторону ИТ»: персонал, серверы, сеть, разработка, проекты, эксплуатация, информационная безопасность. То, как это выглядит «под капотом». Семь зон, где обычно копятся сюрпризы. И тогда, и сейчас, в 2026-м, я смотрю на эти зоны через призму непрерывности бизнеса, оценивая хрупкость, устойчивость, управляемость.

Если вы об этом даже не задумывались, то риск уже есть. Просто он ещё не выставил счёт.

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

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

Всем привет! Меня зовут Анатолий, я работаю ИТ-архитектором в Сбере. Занимаюсь развитием направления клиентской лояльности. Сразу же отмечу, что в этой статье не идёт речь о фундаментально правильных решениях. Скорее, наоборот, речь идёт о решениях компромиссных.

В целом, зрелость архитектурной культуры организации можно оценивать соответствием некому условному уровню. 

Если в вашей компании уже живёт полноценная система для архитектурных решений в виде Aris, Sparx Enterprise Architect или их аналог, и она умеет всё, что нужно: описывать бизнес-сценарии, собирать связанные с ними решения, показывать и согласовывать их с заказчиками, а потом аккуратно складывать в единый архитектурный репозиторий, то тогда, скорее всего, эта статья не для вас. Вы и так всё это проходили.

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

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

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

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

Привычные термины становятся все более запутанными. Если раннее (до 2003 года) система ГОСТ еще была фундаментальна и системно выстроена (причем это были не переводы западных стандартов), то потом система государственной стандартизации стала резко деградировать.

Поговорим про псевдонимизацию?

Есть довольно типичная ситуация в проектах на 1С. На рабочей базе возникает ошибка или нужно доработать нетиповой сценарий. Разработчику желательно получить именно копию базы: на демо-базе ошибка может не воспроизводиться. И тут появляется неприятный вопрос: что еще мы передаем вместе с этой копией?

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

Можно удалить чувствительные данные полностью. Но тогда мы получим уже другую базу, на которой часть исходных сценариев проверить невозможно. Мы попробовали другой подход: обратимую псевдонимизацию базы 1С. То есть перед передачей копии заменять реальные персональные данные правдоподобными синтетическими значениями, сохраняя структуру и связи внутри базы, а после работы подрядчика — при необходимости возвращать исходные значения обратно.

Важно сразу уточнить терминологию. Это именно псевдонимизация, а не необратимая анонимизация: соответствие между исходными и подставными значениями существует и хранится отдельно.

Всем привет! Меня зовут Алёна, я руководитель группы аналитики отдела Compliance и безопасности данных в Ozon. Звучит длинно, поэтому мы с командой называем себя просто датасеками — от Data Security. В информационной безопасности я почти 13 лет, из них 4,5 года в Ozon. До этого больше восьми лет работала в интеграторе и занималась в основном персональными данными и банковской безопасностью — вопросами чистого compliance. Сейчас у меня команда из 11 человек, и мы занимаемся безопасностью данных в Ozon.

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

Привет, Хабр! Меня зовут Максим Темнов, я руковожу департаментом постгарантийной сервисной поддержки (ПГСО) в «РТК-ЦОД». Это девять складов с комплектующими, более ста тысяч «железок» на поддержке и специалисты, готовые привезти и установить ЗИП за считанные часы. Мы выручаем заказчиков с ИТ-оборудованием, когда угасает последняя надежда на его производителей или вендоров. В условиях санкций, штрафов, дефицита на российском рынке и сложных логистических цепочек в хорошем провайдере ПГСО важно… все. Его компетенции и ресурсы — единственная волшебная таблетка для заказчика. В статье расскажу, как обстоят дела с «железом» сейчас и почему паниковать на этот счет не стоит.

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. Недавно в Брно состоялась встреча международного комитета по стандартизации языка программирования C++, в которой я принимал активное участие. В этот раз началась работа над C++29 и как раз о новинках и хочется рассказать.

Инструмент: C4 QuietGridLabs. Можно открыть демо без авторизации: проект будет храниться локально в браузере.

Иногда архитектура «есть» — но пользоваться ею невозможно.

На доске лежит схема сервисов. В Confluence живёт описание. Где-то рядом — sequence-диаграмма, которую никто не открывал с прошлого года. ER-модель хранится в другом инструменте. А когда на ревью возникает простой вопрос «какой endpoint обслуживает этот путь?», команда начинает собирать ответ из памяти, догадок, выдумок, ссылок и исходников.

Я больше 15 лет работаю в ИТ, из них около десяти занимаюсь проектированием и системным дизайном. За это время перепробовал немало: Sparx, ArchiMate, Structurizr, Confluence, whiteboard-сервисы. Я не считаю их плохими — у каждого есть свой сценарий и своя аудитория. Но лично у меня постоянно оставалось ощущение разрыва: диаграмма была отдельно, документация отдельно, а живой контекст системы — в голове у людей.

В какой-то момент моими рабочими спасателями стали whiteboard и VS Code, а позже Cursor. В них можно быстро собрать мысль, оставить немного полезного творческого беспорядка и двигаться дальше. Но они не решали главную проблему: хотелось, чтобы система, её связи, сценарии и документация были одной навигационной моделью.

Так появился C4 QuietGridLabs. Это мой экспериментальный редактор, где C4-модель — это каркас проекта. К элементам можно прикреплять документацию, sequence-диаграммы, ER-диаграммы и описание API, а по связям — переходить от общего ландшафта к конкретным участникам взаимодействия.

Привет, Хабр! Несколько абзацев о том, как понять с помощью проверки живости, что человек, который проходит онлайн‑регистрацию — именно тот, за кого себя выдаёт? Давайте поговорим про лабораторные метрики и реальные показатели, посмотрим, по каким критериям оценивать liveness‑проверки продакт‑менеджерам, решим, насколько можно доверять автоматическим системам и маркетингу вендоров.

Если честно, я давно планировал написать свой язык. Просто надоело на каждом проекте писать одинаковый бойлерплейт, ловить неожиданные ошибки в рантайме, натыкаться на компоненты аля LoanPreloanInterractNDFL6.2ReportViewComponent - и гадать - что имел ввиду художник...

В итоге получился язык "Марка" — штука статически-типозированная, но в которой типы живут во время выполнения, ошибки обрабатываются сами, а из REPL можно сразу дергать запросы и смотреть, что приходит на клиенте и сервере. Как давно мечтал.

Но раскидав исходники по знакомым, получил неутешительный фидбэк: читать трудно! Встал дурацкий вопрос: как это должно выглядеть в коде, чтобы было удобно? Я набросал 4 варианта синтаксиса — от LISP-стиля до почти Python - нотации. У каждого есть плюсы и минусы, и я уже неделю не могу выбрать.

Какой из вариантов читать было бы удобнее лично вам? Проголосуйте!

P.S. Если заинтересовал проект - уже сейчас доступна playground площадка для экспериментов http://marka-lang.ru/playground.php

Российский ИТ-директор, если и слышал об ITIL 5, то мельком: сертификат PeopleCert в стране по-прежнему нельзя купить и сдать напрямую, а хайпа вокруг релиза здесь почти не было.

В статье рассказываю, что в новой версии фреймворка реально изменилось, почему сертификация в России зависла и какие идеи ITIL 5 можно применять уже сейчас — без диплома и без переплаты за модный ярлык.

На всякий случай, если вы не знали, 30-го апреля 2025-го года Правительство утвердило нормативные словари, фиксирующие нормы современного русского литературного языка при его использовании в качестве государственного.

Распоряжением номер 1102-р словари опубликованы на сайте института Русского языка.

Итак, что это за словари?

Когда я начинала карьеру в рекрутинге, всё было проще: резюме писали люди, а не «цифровые агенты», кандидаты самостоятельно проходили собеседования, без помощи ИИ, казалось, еще немного и мы окажемся в чудесном мире будущего... В итоге, в 2026 году IT‑рынок все больше напоминает смесь «Матрицы» с «Голодными играми», и одну из ролей в этой драме играю я.

Меня зовут Татьяна Богословская, я руководитель сектора подбора персонала в Fix Price. Наша компания — это тысячи магазинов, сложная IT‑инфраструктура и команда, которая постоянно растет. Конечно, мы непрерывно ведем подбор и нам очевидно, что в сфере IT началась флоп эра: на рынке много специалистов, но найти и привлечь подходящего кандидата стало труднее. Воронка найма расширилась: теперь приходится проводить гораздо больше интервью, чем раньше. В этой статье я попытаюсь обобщить текущие тенденции и надеюсь, что она будет интересна и кандидатам и коллегам‑рекрутерам.

Как обосновать ИТ-бюджет через FMEA и RCM — методологию надёжности, которой на предприятии уже доверяют