astrobeglec

Количество раз, когда неверный диагноз на жизнеспособность не влиял, не считал, ибо дохуя (как минимум двузначное число). Самое главное, что это не "я такой умный", я человек и тоже ошибаюсь. Поэтому если на приёме говорят Болезнь_1, а я в учебной и научной литературе нахожу, что это скорее всего Болезнь_2, то я не занимаюсь самолечением.

Я иду в платную клинику или беру направление в региональную поликлинику, чтобы более квалифицированные врачи поставили диагноз. И на повторном приёме своего экспертного мнения не раскрываю "поставили Болезнь_1, но я сомневаюсь что-то".

По личной статистике (не утверждаю, что будет работать для всех) где-то в 40 % случаев диагноз вопросов не вызывает, из 60 % оставшихся где-то 60 % (т.е. 36% от всех) в региональной или платной переквалифицируют. А поскольку лечение от Болезни_2 всегда более чем помогает, то сомнений в "исправленном" диагнозе лично у меня не возникает.

Так же отмечу что я из тех, кто "идёт в больницу, когда осколок копья в спине начинает мешает спать"...

Поехали теперь по очередному высеру огрызков.

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

Количество денег в "пироге" "ARM vs. x86" сопоставимо с ВВП России (более 10%) и главная цель огрызков - откусить как можно больше от этого пирога. Кто изучал деятельность этой компании знает, что это классический капиталист - ради прибыли компания всегда идёт на всё.

Если розовых очков не было или они слетели - прошу читать дальше, если нет и "Яблоко - святое" - лепи минус и читай дальше, ибо фанатикам что-то объяснять бесполезно.

Итак, маркетологи Apple очень хорошо вложились в то, чтобы из каждого утюга рассказывали "какие хорошие М-чипы". При этом заказные материалы были настолько хорошо и массово проплачены, что их можно увидеть на всех ресурсах в т.ч. технических. Очень много "авторитетных" специалистов рассказывали "как это хорошо", при этом статьи даже не с критикой, а просто объективных сравнений + и - данных процессоров очень тяжело (хоть и можно) найти.

М-чипы не являются процессорами, это SoC - System-on-a-Chip - система на кристалле, на 1 чипе у нас собрался центральный процессор, видеокарта, оперативная память и ещё ряд систем.

Поскольку я не "тупо хейтер", то сперва опишу плюсы такого подхода, а потом объясню почему Intel и AMD далеко не тупые, такой подход - деградация и почему так делать нельзя.

Плюсы:

1. Всё на одном чипе - нет задержек на передачу данных между узлами

2. Одну и ту же память может использовать процессор и видеокарта

3. Низкая стоимость производства.

Ну а теперь почему так никто не делал и в здравом уме делать не будет:

1. Низкая надёжность. В классической системе выход из строя 1 компонента вынуждает менять только его, здесь выходит из строя сразу всё. Если, например, вышла из строя оперативка, то меняем только её, здесь - меняете всё. И стоимость ремонта устройства на М-чипе легко может сделать х100

2. Низкая адаптивность к задачам. Вычислительными ресурсами обычных ПК можно управлять комбинируя процессоры, оперативную память и видеокарты. Здесь "всё в одном". Если нужная вам программа требует непропорционально больше ОЗУ чем заложено в чипе - вы просто идёте нахуй.

3. Невозможность апгрейда. Когда процессор, ОЗУ, видеокарта - разные устройства, можно апгрейдить ПК частями и подстраивать апгрейды под задачи. В данной системе понятие апгрейда полностью исключено.

4. Неспособность решать все задачи. ARM-чипы, относительно x86 имеют упрощенный набор команд. Часть из "недостающих" команд можно заменить набором команд, часть заменить невозможно. В связи с чем ПО под М-процессоры можно разделить на 3 категории. Если ПО технически не сложное и ему хватает упрощенного набора команд - всё ОК. Если используемый вами софт использует "заменяемые" команды, то он будет сильно тормозить. Если используемый софт работает на "не заменяемых" командах, то его работа на М-чипах просто невозможна.

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

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

Так на что рассчитывают огрызки? На то же самое, что позволило iPhone стать лидером рынка. Массовый пользователь - не компетентный. Для 80 - 90% пользователей нужно всего 5 - 10 % возможностей электронно-вычислительной техники, поэтому пожертвовав 10 - 20 % можно упрощать (деградировать) технику и зарабатывать на этом огромные суммы. А пользователям говорить, что это такой сейчас научно-технический прогресс. Главное говорить громко и с больших сцен.

Небольшой оффтоп - мало кто знает, но в западном мире всё это - обычная практика. Ложь в бизнесе, это как утром одеться - делают все и воспринимают как обычное действие. В рыночной экономике все всегда стараются наебать друг друга и если вас наебали, то с позиции капитализма наёбщик не мошенник, а хороший уважаемый бизнесмен, а если наебал в промышленном масштабе миллионы, то и выдающаяся легенда бизнеса. С ходу вспоминаются такие истории, как радиевые девушки (в начале ХХ века на западе зарабатывали на том, что продавали радиоактивную воду, продукты и т.д. а радиевые девушки - работницы фабрики по производству часов с радиоактивной "подсветкой", количество жертв неизвестно), свинцовый бензин (тетраэтил свинца, который 80 лет травил всё население земли, количество жертв неизвестно), "агент оранж" (дефолианты, которые убивают не только растения но и людей, количество жертв - до миллиона человек) и т.д. То есть "прибыль - это всё", даже если для её получения нужно убивать в масштабах миллионов людей.

Переход на ARM и особенно на М-архитектуру экономически очень выгоден для производителям, поэтому есть большие подвижки у Intel и AMD в этом направлении. Огрызки просто расчищают дорогу и формируют "правильное" общественное мнение, но...

Мало кто уже пробовал тестировать свои решения на М-чипах и ARM-архитектуре, но среди публикаций компаний уже встречаются отзывы о невозможности или высокой стоимости перехода отдельных решений. Среди компаний, с сотрудниками которых я работаю, есть порядка 15% которые должны будут инвестировать большие средства в переход и две, софт которых невозможно использовать на ARM-архитектуре. Если М-чипы сделают ту же революцию деградации, которую сделал iPhone в смартфонах, эти компании уйдут с рынка. Кто считает, что такое невозможно - попробуйте найти смартфон с клавиатурой...

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

Мне не хочется думать о людях, которые попадут в эти доли %.

Чтобы не было "нагнетает" могу описать суть проблемы - есть так называемые "системы реального времени", например, станок должен получать Х команд в секунду. При управлении с х86 компьютера вычисления успевают пройти (с запасом) и станок нормально работает. При попытке использовать ARM-чипы из-за сокращенного количества команд управляющий ПК не успевает обсчитать всё и станок "запарывает" детали.

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

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

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

В приговоре есть ещё немало классных моментов:

1. Виновник пользовался учёткой своего руководителя, знал его логин и пароль. Объяснение "чтобы выполнять обязанности в отсутствии руководителя";

2. Данные выгружались из базы и затем копировались много часов и это ни у кого вопросов не вызвало;

3. Система не отследила перенос 5,7 Гб данных из "защищенной" части в не совсем защищенную;

4. В Сбере у пользователей есть техника, которая не имеет защиту от подключения USB-накопителей, с формулировкой "для служебной необходимости" (видать, чтобы данные воровать удобнее было);

5. В Сбере узнали об утечке данных из Банка России, который обнаружил в открытом доступе 200 из 5000 переданных данных. Если бы не инициирование проверки Банком России то не факт, что СБ Сбера вообще узнала бы о сливе всей своей клиентской базы физлиц;

6. Человек просто взял и вынес на флешке.

7. Человек, который это сделал, явно либо очень далек от ИТ, либо делал всё нагло и практически открыто.

Сперва немного отвечу комментаторам прошлых постов. Как понимаете, приговоры это то, что было выявлено, расследовано, дошло до суда и было опубликовано.

@UBM5UBM, ну что, менеджмент банков безгрешный и никакие данные никуда не сливает? Денег им на всё хватает?

@WhiteredMaH, "невозможно защитить ПД", это имел ввиду, что никто такую лавочку прикрывать не будет?

@RationalVal, ну и чего стоят глубоко разбирающиеся в теме "профессаналы" ИБ Сбербанка? Какая же у них охуенная защита ПД и реальная безопасность.

@pavelkonkov, моя больная фантазия настолько больная, что смогла заразить судей Красногорского городского суда Московской области, которые и вынесли обвинительный приговор по делу. А так же все СМИ, потому что новости о перехваченных продажах данных банков вполне себе регулярные.

А теперь моё заключение.

Я ХЗ сколько Сбер тратит денег на ИБ и сколько макулатуры на это переводит, но...

На скамье подсудимых должен был сидеть не только он. Изучение вопросов защиты информации обычно начинается с Приказ ФСБ России от 10 июля 2014 г. № 378 и постановлением Правительства Российской Федерации от 1 ноября 2012 г. № 1119, у ИБшников обычно это "азбука для самых маленьких" (с этого обычно начинают).

Так вот из фактов, изложенных в приговоре суда СОБЛЮДЕНИЯ требований данных актов я не нашел. Согласно классификации Постановления в Сбере должен обеспечиваться наивысший уровень безопасности (хранение данных более 100к физлиц).

Далее ссылки на Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности (утверждены упомянутым выше приказом ФСБ) и их нарушения (не все, только основные):

1. (пп. в п. 5) Не утверждены, или "только на бумаге" или просто не соблюдаются требования по разграничениям данных и обеспечение доступа в соответствии с должностными обязанностями.

2. (пп. б п. 5) Не обеспечен учёт и порядок хранения носителей информации.

3. (пп. г п. 5) Не буду прям утверждать, но упоминаний о сертифицированных средствах защиты информации в приговоре я так же не нашел. Но использование iPad в отделениях...

4. (пп. 9) Каждый тип защищаемых данных должен быть защищен в соответствии со своим уровнем защиты. Наличие всех данных в одной БД (раз сделана выгрузка) само по себе уже нарушение.

5. (п. 17) Квалификация сотрудников ответственных за ИБ должна обеспечивать полную защиту персональных данных.

6. (пп. б п. 20) Каждый запрос на получение данных и его предоставление должны быть зафиксированы.

7. (п. 22) Все полномочия доступа должны быть прописаны в специальном электронном журнале, все изменения доступов должны фиксироваться. Не реже 1 раза в полгода должна проходить полная сверка.

Я не буду писать ссылки и цитаты на другую нормативку от ФСБ и ФСТЭК (это в 3 - 4 раза раздует пост), но почему за нарушения которой прописаны прямо в приговоре суда никто не ответил?... И к чему это привело? Через 2 года в СМИ опубликовали информацию о новой масштабной утечке по словам представителя Сбера - фейк, однако прозвон данных журналистами РБК (чтобы по формальным причинам пост не закрыли - свидетельство о регистрации СМИ ИА № ФС 77 - 63848) подтвердил, что данные настоящие.

У Сбера официально "утечки не было", но прозвон по взятым наугад номерам все данные почему-то на 100 % подтверждают, полагаю, что принято решение "если нет официальной утечки данных, то и виновных нет и оправдываться не нужно".

После начала СВО за кибератаки уже отчитываются оптом и в основном в % т.е. уже просто не публикуют сколько раз и кого слили.

Безнаказанность порождает безответственность.

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

P.S. Просто ещё раз прочувствуйте - спустя 13 лет после принятия закона 152-ФЗ "О защите персональных данных" и 29 лет после принятия закона 395-1 "О банках и банковской деятельности", где были требования по обеспечению безопасности финансовой информации из ТОП-1 крупнейших банков России всю клиентскую базу по физлицам типичный офисный планктон ПРОСТО ВЫНОСИТ НА ФЛЕШКЕ. Никаких тебе мега взломов, крутых хакеров, операций спецслужб, тайных агентов. Просто типичный (хоть и долго работающий) офисный планктон вынес всю базу на флешке...

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

Второй шаг - психологический. Инфобез, это точно та же война. Только проходит она не в реальности, а в киберпространстве. Что отличает солдата от гражданского? Психология. На 1 месте слово "надо". Броник тяжелый и неудобный? Надо. Ползком неудобно? Но надо. Камуфляж не красивый, но так надо. Солдат, который забывает слово "надо" очень быстро приезжает домой в деревянном ящике. То же самое и про инфобез - расслабился, сделал что-то как захотел, а не как надо... И тебя поимели.

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

1. Классификация данных, определение того какие данные из всех необходимо защищать;

2. Какую цену готовы заплатить за защиту данных;

3. Какими данными можно жертвовать;

4. Какие процессы защищать;

5. Какое количество уровней защиты.

И т.д. и т.п. Последующие шаги будут делаться исходя из стратегических целей.

Для определения стратегических целей нужна полная инвентаризация данных компании (т.е. описание всей инфраструктуры), бизнес-процессов, составление матриц доступа тип данных (публичные данные, для служебного пользования, секретные, особой важности) / круг лиц имеющих доступ к данным. Главный принцип стратегии инфобеза - минимализм:

- хранимых данных должно быть минимальное количество, если что-то можно не хранить - это не должно храниться;

- доступ к каждой категории данных (кроме общедоступных) должен быть у минимально возможного числа лиц, если нет крайней необходимости, то доступа к данным быть не должно;

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

Четвертый шаг - тактика. Каждый стратегический пункт нужно "разложить" в тактическом плане. На каждый тип данных, канал обмена данными, бизнес-процесс составляется матрица возможных угроз и меры по их предотвращению. Я предпочитаю (точнее предпочитал, до выхода из темы) делать это по матрице DCRUD (она является логической переработкой CRUD):

D - Denial of service - Отказ в обслуживании. Сервис и данные всегда должны быть доступны только пользователям у которых есть к ним доступ и недоступны всем остальным.

C - Create - Создание данных должно быть доступно только пользователям с соответствующими полномочиями.

R - Read - Чтение данных должно осуществляться только пользователям с соответствующими полномочиями.

U - Update - Обновление данных должно быть безопасно (можно восстановить всю историю обновления данных) и должно осуществляться только пользователям с соответствующими полномочиями.

D - Delete - Удаление данных недопустимо, данные могут быть помечены как не актуальные, но никогда не удаляться.

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

Практический пример организации защищенного хранилища данных с нулевой утечкой (участвовал специалистом в разработке оного в 2015 - 2016-м году, сфера работы компании - медицина). Поскольку было давно, что-то могу помнить некорректно:

1. Провели инвентаризацию данных. Определили, что защищать нужно ПД клиентов компании (ФИО, паспортные данные), а так же услуги клиентов.

2. Сделали два хранилища - публичное и защищенное. В публичном было всё, кроме защищенных данных.

3. Защищенное хранилище физически размещалось в 2-х зданиях (для обеспечения надёжности хранения, например при пожаре в одном из зданий). Серверные в подвалах, на входе железные двери, внутри пост охраны, сами стойки за отдельной решеткой и ключей у охраны от неё нет. Доступ мог осуществляться только по приказу руководителя, который ЗАРАНЕЕ передавали охраннику, он впускал в назначенное время сотрудника, сотрудник СВОИМ ключом открывал доступ в серверную.

4. Все обмены данными (даже публичными) - зашифрованные, как минимум по 3-м ключам шифрования.

5. Сотрудникам организовали минимальный доступ к информации. Например, фамилию клиента видел только сотрудник проводящий первичную регистрацию. Дальше с клиентом работали только по имени-отчеству и ID.

6. Направления на анализы выдавались по UUID, результаты привязывались так же к UUID. Никаких фамилий и имён. Связь пациента и UUID анализа - в защищенном хранилище.

7. Сотрудники носили форму вообще без карманов, любая техника - запрещена. Из оборудования (кроме мед. приборов) разрешались только механические ручные часы. Нарушение правила - безусловное увольнение.

8. На рабочих ПК - урезанный до предела Linux, браузер в режиме киоска + самописная СКЗИ. По времени визита клиента выдавалась только минимум информации.

9. Никакой беспроводной связи. Все кабели с данными только с изоляцией и шумоподавлением в защищенных кабель-каналах с сигнализацией повреждения.

10. Никакого удаленного доступа. Вообще никакого и вообще никому.

11. Все обмены данными строго по "белым спискам" с логированием в журналах;

Защищенное хранилище технически представляло собой 5 серверов (начинка как у обычных ПК) + станция администрирования:

1. Станция администрирования - ПК с которого был доступ к серверам. Каждый сервер имел 2 сетевые карты, 1 сетевая в "общую" сеть и 1 в коммутатор к станции администрирования. Доступ к SSH только через порт 2 (только с IP и MAC станции администрирования и сервера бэкапов).

2. Сервер бэкапов. Сервер все бэкапы забирал сам мог подключаться к остальным серверам.

3. Сервер ключей шифрования. Сервер генирировал и хранил все необходимые ключи шифрования данных.

4. Сервер баз данных. База данных с полным запретом стандартных операций (SELECT, INSERT, UPDATE, DELETE). Все операции только через DDL, в каждой DDL обязательное журналирование всех операций. В таблицы допускалось только добавление строк, UPDATE, DELETE в DDL запрещены. Каждая запись, вместе с ЭЦП прошлой записи подписывается ЭЦП.

5. Сервер приложений. На данном сервере хранились микроприложения, которые работали с БД, IP-АТС и рассылки СМС. 1 задача - 1 приложение. Рассылки СМС брались напрямую из БД, на звонки динамически выделялись номера. То есть номер 0001 сейчас перенаправляется на +7 912 345 68 89, а через 5 минут на +7 912 345 89 68. Каждый сотрудник звонил только на "свой" номер. Т.е. если пациент не пришел, то "свой" номер врача указывал на номер пациента, который записан на текущий момент.

   Ни одно из приложений не было больше 1000 строк кода.

6. Сервер управления, который рулил всем вышеперечисленным.

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

Организация операций с данными от регистрации клиента до архивации:

1. Новый клиент заключает договор, его данные вносятся в форму, распечатывается подписывается. СКЗИ регистратуры шифрует каждый тип данных (фамилия отдельно, дата рождения отдельно, телефон отдельно, паспортные данные отдельно и т.д.) публичными ключами и полученные данные отправляет серверу приложений. Данные шифруются ключом рабочей станции и ключом сотрудника. Сервер приложений получает зашифрованные данные. По IP отправителя отправляет данные на расшифровку, потом по информации сервера управления отправляет данные на расшифровку ключом сотрудника, полученные данные отправляет в DDL СУБД (обращаем внимание - БЕЗ РАСШИФРОВКИ). Бумажная копия документов сразу упаковывается в конверт, опечатывается и сдается в архив. Из публичных данных остаётся только хеш номера телефона (так хранятся пароли).

2. При необходимости оказания услуги клиент называет номер телефона, его вбивают, так же шифруют ключом ПК и сотрудника, сервер приложений так же расшифровывает и возвращает по хешу телефона (из публичной части) UUID клиента зашифрованный ключами ПК и сотрудника.

3. Клиенту делается запись на время Х к врачу. Данные по записи так же шифруются и передаются в формате дата-время-UUID клиента-UUID врача.

4. По расписанию приёма сервер управления запрашивает связки UUID клиента и UUID врача. Сервер приложений получает команду на формирование пакета данных, которые будут отправлены на ПК врача - имя и отчество клиента, минимальные данные по профилю (т.е. врач видит только "свои" данные, историю посещений по своему профилю и результаты своих анализов). Данные шифруются ключом ПК врача и ключом самого врача.

5. Направление на анализы - так же по UUID. На направлении нет ни ФИО, ни возраста, ничего. UUID и список исследований.

6. Лаборатория вносит результаты так же по UUID.

Обращу внимание:

1. Все передачи данных идут строго по одной. Списки исключены полностью.

2. Все данные шифруются ПОСЛЕДОВАТЕЛЬНО ключами оборудования, сотрудников и сервисов. Расшифровка возможна ТОЛЬКО на том оборудовании куда идут данные и только сотрудником, которому данные предназначены;

3. Ключ оборудования прописан только в самом оборудовании, ключ сотрудника - на токене / флешке. Токен получается в начале рабочего дня под запись и сдаётся в конце рабочего дня так же под запись.

4. Защищаемые данные в открытом виде не хранятся НИГДЕ.

5. Все данные НИКОМУ и НИКОГДА не предоставляются.

6. Нарушение порядков обмена данными - алармы и журналы.

ОК, давайте представим, что конкуренты решили слить себе данные, что для этого нужно:

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

2. Украсть все ключи запуска серверов у всех сотрудников.

3. Выкрасть всех разработчиков. Проект разрабатывало 7 человек. Каждый отвечал только за свой участок и защиту своего сектора. "В целом" работу системы понимали все, но конкретики по "чужим" участкам ни у кого не было.

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

Почему другие варианты не сработают?

1. "Засланные казачки" бесполезны. Просто потому что "точки слива" нет. Допустим решили получить данные на Х. Для этого нужно знать номер телефона, по которому он зарегистрировался, создать фиктивную запись к врачу, ОПЛАТИТЬ её и получить часть данных по его профилю. С учётом смсок с информированием о записи клиент вполне себе может и вопросы задать. А ответы в логах доступа - кто записывал, с какого рабочего места...

2. Просто запоминать? А что именно? Врач видит, что к нему пришел 3 раз Иван Иванович (фамилию и дату рождения не видит), который сдал такие-то анализы с таким-то результатом. Сфоткать экран нечем, да и смысл? Информации о том был ли Иван Иванович у других врачей и что он там делал - нет. Да и какой именно Иван Иванович - ХЗ, ибо людей с одинаковыми именами-отчествами полно. Бухи видят оплаты, но не видят и не знают кто платил...

3. В регистратуре есть информация о человеке (при регистрации), больше - ничего (он ещё обследований не проходил).

4. При повторном обращении есть UUID и куда пошел человек. Больше - ничего.

5. В лаборатории есть информация, что по UUID есть такие-то результаты анализов. Больше - ничего.

P.S. У данной истории печальный финал. Система отработала несколько лет, прошла проверки в т.ч. по 152-ФЗ, а потом главврач клиники сменился. Новый систему заменил на "более продвинутую, менее сложную от одного из лидеров обеспечения безопасности персональных данных".

Для удобства переноса данных мы её быстро (за 15 минут) "ломанули" и за пару дней перетащили все данные (потребовалось участие всех разработчиков и всех админов). "Ломанули за 15 минут", это не хвастовство и не зря в кавычках - просто эта система имела уровень защиты исключительно от технически неграмотных честных людей, ибо в личных настройках ВСЕХ ПОЛЬЗОВАТЕЛЕЙ (правда довольно глубоко) был логин/пароль к центральной БД в открытом виде, БД разрешала удаленные подключения, а внутри БД разграничений доступа не было от слова совсем.

Самая большая проблема в том, что в банках работают люди...

Отмечал несколько раз, что при отказе в кредите (это происходит в нескольких банках), буквально в течении часа прилетает поток звонков от других банков и МФО. Иногда между отказом и первым звонком - секунды. Это значит, что слив персональных данных идёт на уровне ТОП-менеджмента этих самых банков и зашит в банковские приложения. То есть есть два варианта:

1. Есть менеджер, который продаёт данные конкурентам, есть разработчик, который этот слив написал и есть безопасник / сисадмин, который "прикрывает" канал слива данных.

2. То же самое, но без менеджера.

Сильно сомневаюсь, что такие вещи делаются бесплатно, а значит есть несколько лиц, которые зарабатывают (и полагаю не 3 копейки) на сливе данных. Очевидно, что эти люди не хотят лишаться дохода и тем более менять крутой московский офис на нары в Магадане. Естественно, такие люди на совещании не скажут - мы тут вашими данными барыжим и хотелось бы не сворачивать, поэтому палки в колёса будут ставить молча, но оптом.

Государство приняло решение о защите ПД. Тут помимо указанной выше "команды" пойдут следующие проблемы:

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

2. В нормальной структуре крупной организации руководитель ИБ (который должен запустить закон в действие) входит в высший эшелон управления (прямое подчинение гендиру / совету директоров). Если не так, то это "козёл отпущения типичный". То есть с учётом подлянке из п. 1 в штат нужно ввести "человека с улицы", причём ввести на самый верх. А "люди с улицы" имеют сразу несколько проблем для менеджмента всех уровней:

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

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

   - ИБ накладывает очень неудобные профдеформации (там много идейных), которые договариваться или не будут, или "договоряться", но при первом удобном случае сольют;

   - по должности ИБшник может нагнуть почти любого, а вот наоборот - почти нереально;

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

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

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

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

   - много не формализованных процессов, а из формализованных очень много "через жопу". И всё это г-но всплывёт вверх;

   - начИБ может указать точку проблемы и суть проблемы, а вот решение и как его встроить - задача руководителя, который отвечает за участок. ВНЕЗАПНО окажется, что довольно много управленцев - идиоты и не факт, что обойдётся без кадровых решений;

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

   - поскольку процессы изменились, изменяются и процессы управления. Создать или поправить процесс, это совсем не то, что по инерции поддерживать кем-то построенное ранее процесс. Это принципиально разные вещи. "Новый" банк вполне может стать неуправляемым.

   Можно сказать, что раньше менеджер ездил на Лексусе, а теперь его пересаживают на БМП-3...

5. Технический пункт. Приложение и безопасное приложение, это ОЧЕНЬ разные приложения. Кто читает компьютерную литературу, тот возможно замечал, что безопасности там внимание практически не уделяется. А про обеспечение абсолютной безопасности вопросы поднимаются реже, чем жемчужины на берегу встречаются. Более того, очень много "общепринятых правил" прямо конфликтуют с высокими уровнями ИБ.

   Грубо говоря "обычный программист" учился делать обычные мерседесы, а тут приходят и ставят задачу, что вот это вот нужно переделать так, чтобы в лоб РПГ-7 держал... Общего между А и Б примерно столько же, сколько между тем же мерседесом и Т-90, а у них - лапки.

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

6. После всего этого окажется ещё один страшный для менеджмента момент. Безопасность, это долго. До 5 - 8 раз. То есть если "как получится" 1 фишка в неделю на программиста, то при работе с защищаемыми данными (а там почти все такие) будет 1 фишка в 5 - 8 недель на программиста.

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

В банках (имеется ввиду уровень интересов сотрудников) защищать данные клиентов не интересно никому, следовательно этому процессу будут вставлять палки в колёса (кстати, то же самое происходило и с импортозамещением. На бумаге - импортозаместились, по факту ЕС и США заменили на Китай).

Почему я в этом уверен? Потому что банкиры сами это признали:

Банки предлагают отменить введение оборотных штрафов за повторную утечку персональных данных в размере до 500 млн руб. «Вызывает обоснованные сомнения тезис о том, что уплата столь значительных штрафов может заставить компании наращивать инвестиции в информационную безопасность (ИБ), поскольку все последние годы расходы на ИБ и без того растут на десятки процентов ежегодно. Напротив, при введении административной ответственности даже просто в силу самого факта утечки персональных данных при отсутствии вины компании ее средства будут уходить на уплату оборотных штрафов, а не на развитие ИБ. Крупный штраф может действовать как стимул только тогда, когда организации могут предотвратить его уплату своими добросовестными действиями», — говорится в письме НСФР.

Первоисточник

То есть представители банков в открытую говорят, что данные будут утекать и утекать многократно (возмущены частью с ПОВТОРНЫМИ утечками), вопросы ИБ рассматриваются только как финансовые (формулировка "инвестиции в ИБ", следовательно вариант замены идиотов на квалифицированных специалистов не рассматриваются), все действия делаются и будут делаться только формально (фраза "при отсутствии вины компании"), на обеспечение результата никто работать и не думает (фраза "предотвратить ... добросовестными действиями")...

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

Уровень управленцев, которые это подписали неприятно поражает. Фразу выше можно переписать как: "Руководство и ТОП-менеджмент нашего банка некомпетентны в ключевых вопросах (а для банка надёжность - один из ключевых показателей), но зарплаты нам нравятся, поэтому мы хотим чтобы завтра было как вчера и ничего не менялось".

P.S. Если будет интересно, то могу коротко написать чем системы с ориентированием на безопасность отличаются от "обычных".

1. Нарушения сроков и порядка взыскания - обычное дело, это правило, а не исключение.

2. Кадровый голод, поэтому руководство особо не наказывает сотрудников. Из-за этого:

3. Почти поголовный синдром вахтёров и крайняя степень охуевания у сотрудников.

4. На свои обязанности большинство приставов кладут хуй, даже если его нет.

Пример из жизни:

У меня есть просроченная карта, которую не могу закрыть и которая будет со мной до конца жизни, потому что:

- в 2015-м году выписали штраф, вовремя оплатил;

- в ГИБДД кто-то накосячил и штраф пошел как не оплаченный в мировой суд;

- мировой судья вынес судебный приказ, но ничего мне не прислал;

- пристав, которому попал приказ, молча сделал списание и наложил арест на счета.

Штраф - 200 рублей, но все счета заблокированы.

- иду в банк, дают постановление по которому было дело;

- иду к приставам - получаю приказ;

- иду в ГИБДД с квитанцией, они признают косяк, пишут в суд "отказную";

- судья аннулирует судебный приказ, отношу в ФССП, где мне говорят, что аресты снимут в течении недели...

Месяц тишины.

- беру у судьи 2 экземпляр решения, отношу в банк. Счета разблокируют, но арест 200 руб. на карте остаётся в силе. Да-да до сих пор.

На ...дцатой жалобе и ответами "да-да вот завтра арест снимем" во все возможные и невозможные инстанции я просто смирился с тем, что у меня есть "вечная карта" с замороженными на ней 200 руб.

Недавно по этой же схеме у меня опять заблокировали счета из-за оплаченного за год до этого штрафа (оплаченного через Госуслуги, кстати, на следующий день после постановления). С каждого открытого счёта списали сумму штрафа...

Для тех, кто далёк от юриспруденции, в п. 12 ст. 30 Федерального закона от 02.10.2007 г. № 229-ФЗ "Об исполнительном производстве" у должника от факта получения постановления есть 5 дней на добровольное погашение. Постановление - ознакомление должника - 5 дней - взыскание.

А теперь следите за руками:

День Х:

- постановление о возбуждении исполнительного производства "по данным ГИС" т.е. вообще без исполнительного документа;

- обращение взыскания на все счета во всех банках через постановление;

День Х + 1:

- сходил в ГИБДД, показали, что в их БД стоит оплата штрафа, т.е. по данным ГИС всё оплачено.

- пошел к приставам - послали нахуй. Вот прям в лицо сказали что со мной разговаривать не будут;

- жалоба на действия пристава через Госуслуги (прям в здании ФССП писал);

День Х + 3:

- ответ от начальника ФССП через Госуслуги, что "при проверке нарушений не выявлено";

- жалоба в прокуратуру на пристава и начальника ФССП;

День Х + 5:

- уведомление о возбуждении исполнительного производства приходит через Госуслуги;

День Х + 6:

- все деньги с арестованных счетов вернулись назад на эти же счета.

День Х + 15:

- ответ от прокуратуры, что в действиях пристава, начальника ФССП нарушений не усматривается...