Отмечу, что рассматривается ситуация, когда нарушителю известны пароли и другая аутентификационная информация (например, брелки iButton и др.) используемая для защиты ключей от НСД.
На текущий момент, подобную защиту вы сможете обеспечить только если применяется честная схема с ФКН и (или) применяются HSM.
В типовой конфигурации УЦ используют следующие ключи:
1. Ключ самого УЦ или как он раньше назывался ключ уполномоченного лица удостоверяющего центра.
В типовом случае хранится в реестре CA (ФСБ в тоже время требует, чтобы использовался отчуждаемый носитель), для защиты применяют АПМДЗ Соболь или Аккорд. По хорошему должен хранится в HSM. Копирование ключа (если не используется HSM) возможно следующими способами:
— при наличии аутентификационной информации (паролей, идентификаторов iButton и др.) штатными средствами СКЗИ;
— при доступе к резервных копиям УЦ.
— из оперативной памяти, при наличии возможности запуска кода с правами Local System;
— из файла подкачки.
— при совершении сервисного обслуживания техники.
Если ключ хранится на отчуждаемом носителе (не ФКН) в сервной, то копирование возможно способами как указано далее.
2. Ключи авторизации работников УЦ. Данные ключи используются для авторизации персонала при осуществлении доступа к критически важным функциям таким как выпуск сертификата, заведение нового пользователя, отзыв сертификата, выпуск CRL и т.д. Как правильно данные ключи хранятся на «обычных» токенах, защищенных паролем + используется СКЗИ, от производителя УЦ.
Скопировать возможно следующими способами:
1. Штатными средствами СКЗИ (при наличии паролей от токенов)
2. Путем предвартиельного получения пароля от токена: соц. инжинирия, трояны.
3. Путем перехвата ключа в канале связи между компом и токеном: usbCAP, трояны
3. Инфраструктуре ключи, например ключи для организации TLS до Web-интефрейса УЦ. Обычно хранятся в реестре или в файлах. Способы копирования перечислены выше.
4. Ключи пользователей УЦ. Здесь я надеюсь, что у вас хранятся только открытые ключи. Хранение закрытых ключей на стороне УЦ дискредитирует всю схему PKI.
Ну и наконец универсальный способ (без принятия мер защиты) копирования любых ключей — side channel атаки, включая применение СТС (специальных технических средств негласного съема информации) и всеми горячо нелюбимый ПЭМИН.
Поэтому утверждение что в вашем УЦ нельзя скопировать ключи — довольно смелое :), корректней было бы сказать, что злоумышленник обладающий суммой X-рублей не сможет скопировать у вас ключи.
P.S. Кроме это по мимо ключей УЦ вы наверняка еще пользутесь услугами дистанционного банковского обслуживания Интернет Клиент-Банк, а это отдельная песня.
Скопировать ключи можно не с любых токенов, но довольно с многих.
Галкой «неизвлекамый» — вы наварено называете «не экспортируемый». Стоит отметить, что наличие данной галки — обрабатывается только СКЗИ. А это значит, что если ключевая информация доступна в обход СКЗИ (например, ключ хранятся на флешке или в реестре), то она может быть успешно скопирована не смотря на галку.
Таким образом, ответить на ваш вопрос о возможности копирования ключей, для которых стоит галка «не экспортируемый» можно следующим образом:
— Если к ключевой информации можно обратится в обход СКЗИ, то не смотря на эту галку их скопировать можно.
Применительно к токенам обходные маневры расписаны в статье
УЦ по распределенной схеме галки не ставит вообще никакие, так ключевую пару генерирует пользователь.
А по централизованной схеме, кто во что горазд.
У меня лично был опыт, когда при генерации ключа для ДБО ИКБ меня пустили за компьютер офицера безопасности Банка, ответственного за генерацию ключей, хотя в Банке я был впервые. Поэтому утверждать, что там делает УЦ по централизованной схеме это более чем смело.
А по поводу извлечения ключей — предлагаю просто попробовать. Возьмите (если у вас есть к ним доступ) ключи в вашей организации и попробуйте их скопировать :)
Я думаю после этого вы посмотрите на проблему под другим углом.
Уважаемый коллега, из КРИПТО-ПРО, согласен что аббревиатура ФКН это «ваше изобретение» (в хорошем смысле)
Когда писал статью, долго думал как назвать «токены с не извлекаемым ключом» по науке. Вы в своих статьях упоминаете термины «активный вычислитель» и др., на мой взгляд предлагаемые термины немного сложны для понимания не криптографам.
С другой стороны Функциональный ключевой носитель (ФКН) — сообщает базовые характеристики устройства:
— выполнение функций,
— хранение ключа.
Другое дело в том, что ваша реализации ФКН, возможно более продвинутая по сравнению с другими (ФКН от КРИПТО-ПРО, обеспечивает защиту канала связи между токеном и ЭВМ).
Таким образом термин ФКН на мой взгляд наиболее удачен в данном случае.
Давайте еще раз разберемся в чем разница между «не экспортируемым» ключом и «неизвлекаемым».
Например вы сгененрировали ключ и поставили галку что ключ неэкспортируемый. Что это значит? А значит это, то что средствами СКЗИ его скопировать не получиться. Но когда выполняется подпись документа, ключ с токена копируется в память ЭВМ, где обрабатывается криптопровайдером, Основной баг этой схемы в том, что ключ может быть похищен из ОЗУ.
Галочку что ключ «не экспортирумый» можно поставить и при генерации ключа на обычном токене, для этого необязательно покупть более дорогой токен с «неивзлекамым ключом».
Теперь рассмотрим неизвлекаемые ключи. В этой схеме ключи, хранящиеся на токенах никогда не подают в память ЭВМ все криптографические операции связанные с использованием ключа выполняются сугубо на токене. Таким образом ключ скоприровать невозможно.
В этом принципиальное отличие.
Суть статьи в том, что вы берете устройство — токен, заходите на сайт производителя, там везде токен с неизвлекаемым ключом это очень круто, безопасно и т.д. (с чем я согласен :)
Берете свое СКЗИ используете этот токен — СКЗИ работает, файлы подписываются, и у вас может сложится ложное мнение о том, что ваша схема — это схема с ФКН, но на самом деле нет.
На примере JaCarta — http://aladdin-rd.ru/catalog/jacarta/gost/specification. В ней исползуется чип — http://pdf1.alldatasheet.com/datasheet-pdf/view/255626/ATMEL/AT90SC25672RCT.html
Автор, подскажите… какой именно функционал содержит апплет в аппаратной части?
Про функционал не подскажу, этот вопрос лучше адресовать производителям токенов. Неплохая документация по токенам — http://dev.rutoken.ru/
Точнее: можно ли с помощью него реализовать шифрование ГОСТ без установки ГОСТ-криптобиблиотек непосредственно на рабочую станцию.
В общем случае так сделать нельзя. Прикладное ПО (например, MS outlook) обращается к крипторафическим библиотека по какому либо стандартному интерфейсу, например MS CryptoAPI. Для того чтобы этот интерфейс был доступен и нужны криптопровайдеры. НО. Можно пойти по пути как сделал КриптоАРМ. Они умеют самостоятельно общаться с токеном, фактически реализуя встроенную криптобиблиотеку.
УЦ — обычно применяют распределенную схему генерации ключей. В данной схеме они ожидают от нас запрос на сертификат + подписанные бумажки, после получения которых они выпускают сертификат. Генерацию ключей и размещение их на носителях осуществляет пользователь.
Но когда вы «покупаете подпись», то вам скорее всего понадобятся СКЗИ и токены, вот здесь и проявляют себя продавцы в полную силу и начинают продавать то, что вам не надо.
Вбить в конфиг и сохранить в файл или построить работающую сеть, использующую оборудование и операционные системы реализующие стандартные сетевые технологии?
Как кратко записать маску 255.0.255.0? Например, 255.255.255.0 получаем маску /24, а в вашем случае какая краткая маска получится?
Те ваш бэк коннект фактически эквивалентен пробросу порта на фаере и фильтрации подключений на конечных хостах?
С точки зрения функционала — да.
С точки зрения безопасности, вариант с межсетевым экраном шлюзового типа (железка то есть) проигрывает, потому как для описания правил фильтрации используются IP-адреса, а они могут быть подменены с помощью IP-spoofing. В тоже время применение локального межестевого экрана в технологии back connect лишено указной проблемы, поскольку он настраивается на фильтрацию в криптографически защищенном соединении (туннеле), в котором не возможна подмена данных.
На практике, back connect следует применять, только там где передается информация особой важности, например передача трафика содержащего аутентификационную информацию, или сведения о переводах денежных средств или управляющие воздействия автоматизированных систем управления технологическими процессами (АСУ ТП).
Более приземленным вариантом может быть защита взаимодействия RO DC c полнофункциональными контролерами домена. В некоторых схема high-security все пользователи авторизуются всегда через RO DC, а администрирование происходит на глубоко спрятанных полнофункциональных контролерах.
Те сам по себе EOL, без известных проблем, не проблема?
Проблема. И заключается она в том, что уязвимости в нем не публикуются, хотя это вовсе не значит что их нет. Пример Windows XP.
А вот это хороший вопрос. Проблема в том, что сетевая служба ожидающая подключение по порту может содержать уязвимости в коде и быть атакована Нарушителем.
Это можно проиллюстрировать на примере с Heartbleed уязвимостью и Web — приложением проводящим авторизацию на примере форм (Web выбран в только в качестве примера, аналогичная схемы может быть актуальна и для других сервисов).
Здесь неуполномоченные пользователи «отсекаются» авторизацией Web-приложения и вроде бы сервис защищен, но Нарушители могут атаковать непосредственно саму сетевую службу (в данном случае ее компонент — OpenSSL). Дабы не бороться с каждой подобной уязвимостью технология back connect позволяет закрыть сам канал атаки.
Почему вы считаете что EOL сетевого оборудование сам по себе проблема?
Наиболее понятным примером будут ошибки в BMC серверов, для которых нет патчей (не в природе, а для данной модели сервера) и из-за которого приходится этот функционал отключать.
Мы с вами рассуждаем о межсетевых экранов разного типа (поколения).
То что вы говорите — это пакетный фильтр, который принимает решение о транзите трафика только на основании данных заголовков.
В статье и моих коментах я оперирую правилами межсетевых экранов работающих с анализом состояния (stateful firewall) В них правила фильтрации помимо адресов учитывают состояния например new, established, invalid,… примером межсетевого экрана подобного класса является iptables. Поэтому при описании правил и применялась фраза — «разрешить инициацию соединений из внутренней сети в DMZ».
Оба типа межсетевых экранов применяются на практике. Пакетные фильтры используются на магистралях, где важна скорость. Statefull применяются на уровне сегментов корпоративных сетей, где важна защита от обхода с помощью фрагментации
В случае заражения АРМ внутри сети он всё равно сможет долбить сервер в локалке, поскольку ему разрешено с ним работать, либо не сможет потому что у него туда доступа нет, тут туннели вообще не причём.
Back connect — технология защиты межсерверных связей. Пример ее использования — связь с сервера приложений (того, что обслуживает клиентов) с сервером баз данных. Сервер БД в данном случае будет инициатором построения туннелей и соответственно не будет иметь открытых портов by design. Почему это важно?
На практике, случаются случаи когда на защиту с помощью сетевых устройств нельзя положится на 100%. Это могут быть случаи когда:
сетевые устройства не находится на поддержке производителя и не обновляются,
сетевые устройства управляются на аутсорсинге
квалификация администраторов недостаточна высока.
Другим примером ее использования обеспечение второго контура безопасности для защиты особо важных данных. Про актуальность этих задач можно посмотреть тут.
Это значит что используются исключительно виртуальные машины и между ними нет железных девайсов и сетевых устройств в привычном понимании.
Потому что туннели ничего кроме лишней административной работы и нагрузки CPU не дадут, всё тоже самое легко делается пробросом портов на фаерволе и правилами.
Туннель позволяет не открывать порт на сервере и не делать правила на межсетевом экране (проброс портов). Зачем это нужно ответил в статье.
А у вас тут соединяются свои сервера, не ужели в локалке настолько помойка и бардак что к ней нет доверия и никак это нельзя исправить?
Нет помойки, есть информация, стоимость которой весьма высока.
Хочу подчеркнуть важный момент. В статье приводятся только одни из возможных вариантов, они не являются единствено возможными.
Если хочется сравнить несколько вариантов по защищенности то это надо делать на моделе угроз.
Если сравнивать варианты по затратам то лучше это делать по стоимости владения (TCO) в 3 или 5 летней перспективе.
Если «сперли бабки» с карты надо делать так:
1. В течение 23 часов 50 минут звонить в КЦ (контакт центр), при этом желательно разговор записать, предупредив об этом сотрудника КЦ и попросить его назвать дату и время звонка.
2. В ходе разговора с КЦ детально описать суть оспариваемой транзакции.
3. После разговора с КЦ написать письменное заявление обязательно указав, что вы хотите что бы Банк вернул вам денежные средства.
4. Ждать ответа банка в течение 30 дней по Российским транзакциям и 60 по международным.
5. Если Банк не ответил то обращаемся в ЦБ.
6. Хуже не будет если написать заявление в полицию по факту кражи.
Отмечу, что рассматривается ситуация, когда нарушителю известны пароли и другая аутентификационная информация (например, брелки iButton и др.) используемая для защиты ключей от НСД.
На текущий момент, подобную защиту вы сможете обеспечить только если применяется честная схема с ФКН и (или) применяются HSM.
В типовой конфигурации УЦ используют следующие ключи:
1. Ключ самого УЦ или как он раньше назывался ключ уполномоченного лица удостоверяющего центра.
В типовом случае хранится в реестре CA (ФСБ в тоже время требует, чтобы использовался отчуждаемый носитель), для защиты применяют АПМДЗ Соболь или Аккорд. По хорошему должен хранится в HSM. Копирование ключа (если не используется HSM) возможно следующими способами:
— при наличии аутентификационной информации (паролей, идентификаторов iButton и др.) штатными средствами СКЗИ;
— при доступе к резервных копиям УЦ.
— из оперативной памяти, при наличии возможности запуска кода с правами Local System;
— из файла подкачки.
— при совершении сервисного обслуживания техники.
Если ключ хранится на отчуждаемом носителе (не ФКН) в сервной, то копирование возможно способами как указано далее.
2. Ключи авторизации работников УЦ. Данные ключи используются для авторизации персонала при осуществлении доступа к критически важным функциям таким как выпуск сертификата, заведение нового пользователя, отзыв сертификата, выпуск CRL и т.д. Как правильно данные ключи хранятся на «обычных» токенах, защищенных паролем + используется СКЗИ, от производителя УЦ.
Скопировать возможно следующими способами:
1. Штатными средствами СКЗИ (при наличии паролей от токенов)
2. Путем предвартиельного получения пароля от токена: соц. инжинирия, трояны.
3. Путем перехвата ключа в канале связи между компом и токеном: usbCAP, трояны
3. Инфраструктуре ключи, например ключи для организации TLS до Web-интефрейса УЦ. Обычно хранятся в реестре или в файлах. Способы копирования перечислены выше.
4. Ключи пользователей УЦ. Здесь я надеюсь, что у вас хранятся только открытые ключи. Хранение закрытых ключей на стороне УЦ дискредитирует всю схему PKI.
Ну и наконец универсальный способ (без принятия мер защиты) копирования любых ключей — side channel атаки, включая применение СТС (специальных технических средств негласного съема информации) и всеми горячо нелюбимый ПЭМИН.
Поэтому утверждение что в вашем УЦ нельзя скопировать ключи — довольно смелое :), корректней было бы сказать, что злоумышленник обладающий суммой X-рублей не сможет скопировать у вас ключи.
P.S. Кроме это по мимо ключей УЦ вы наверняка еще пользутесь услугами дистанционного банковского обслуживания Интернет Клиент-Банк, а это отдельная песня.
Галкой «неизвлекамый» — вы наварено называете «не экспортируемый». Стоит отметить, что наличие данной галки — обрабатывается только СКЗИ. А это значит, что если ключевая информация доступна в обход СКЗИ (например, ключ хранятся на флешке или в реестре), то она может быть успешно скопирована не смотря на галку.
Таким образом, ответить на ваш вопрос о возможности копирования ключей, для которых стоит галка «не экспортируемый» можно следующим образом:
— Если к ключевой информации можно обратится в обход СКЗИ, то не смотря на эту галку их скопировать можно.
Применительно к токенам обходные маневры расписаны в статье
А по централизованной схеме, кто во что горазд.
У меня лично был опыт, когда при генерации ключа для ДБО ИКБ меня пустили за компьютер офицера безопасности Банка, ответственного за генерацию ключей, хотя в Банке я был впервые. Поэтому утверждать, что там делает УЦ по централизованной схеме это более чем смело.
А по поводу извлечения ключей — предлагаю просто попробовать. Возьмите (если у вас есть к ним доступ) ключи в вашей организации и попробуйте их скопировать :)
Я думаю после этого вы посмотрите на проблему под другим углом.
Когда писал статью, долго думал как назвать «токены с не извлекаемым ключом» по науке. Вы в своих статьях упоминаете термины «активный вычислитель» и др., на мой взгляд предлагаемые термины немного сложны для понимания не криптографам.
С другой стороны Функциональный ключевой носитель (ФКН) — сообщает базовые характеристики устройства:
— выполнение функций,
— хранение ключа.
Другое дело в том, что ваша реализации ФКН, возможно более продвинутая по сравнению с другими (ФКН от КРИПТО-ПРО, обеспечивает защиту канала связи между токеном и ЭВМ).
Таким образом термин ФКН на мой взгляд наиболее удачен в данном случае.
Давайте еще раз разберемся в чем разница между «не экспортируемым» ключом и «неизвлекаемым».
Например вы сгененрировали ключ и поставили галку что ключ неэкспортируемый. Что это значит? А значит это, то что средствами СКЗИ его скопировать не получиться. Но когда выполняется подпись документа, ключ с токена копируется в память ЭВМ, где обрабатывается криптопровайдером, Основной баг этой схемы в том, что ключ может быть похищен из ОЗУ.
Галочку что ключ «не экспортирумый» можно поставить и при генерации ключа на обычном токене, для этого необязательно покупть более дорогой токен с «неивзлекамым ключом».
Теперь рассмотрим неизвлекаемые ключи. В этой схеме ключи, хранящиеся на токенах никогда не подают в память ЭВМ все криптографические операции связанные с использованием ключа выполняются сугубо на токене. Таким образом ключ скоприровать невозможно.
В этом принципиальное отличие.
Суть статьи в том, что вы берете устройство — токен, заходите на сайт производителя, там везде токен с неизвлекаемым ключом это очень круто, безопасно и т.д. (с чем я согласен :)
Берете свое СКЗИ используете этот токен — СКЗИ работает, файлы подписываются, и у вас может сложится ложное мнение о том, что ваша схема — это схема с ФКН, но на самом деле нет.
Проблема в том, что описываемый в статье случай, это что-то из разряда ввода потребителя в заблуждение.
На примере JaCarta — http://aladdin-rd.ru/catalog/jacarta/gost/specification. В ней исползуется чип — http://pdf1.alldatasheet.com/datasheet-pdf/view/255626/ATMEL/AT90SC25672RCT.html
Про функционал не подскажу, этот вопрос лучше адресовать производителям токенов. Неплохая документация по токенам — http://dev.rutoken.ru/
В общем случае так сделать нельзя. Прикладное ПО (например, MS outlook) обращается к крипторафическим библиотека по какому либо стандартному интерфейсу, например MS CryptoAPI. Для того чтобы этот интерфейс был доступен и нужны криптопровайдеры. НО. Можно пойти по пути как сделал КриптоАРМ. Они умеют самостоятельно общаться с токеном, фактически реализуя встроенную криптобиблиотеку.
УЦ — обычно применяют распределенную схему генерации ключей. В данной схеме они ожидают от нас запрос на сертификат + подписанные бумажки, после получения которых они выпускают сертификат. Генерацию ключей и размещение их на носителях осуществляет пользователь.
Но когда вы «покупаете подпись», то вам скорее всего понадобятся СКЗИ и токены, вот здесь и проявляют себя продавцы в полную силу и начинают продавать то, что вам не надо.
Каким образом броадкаст пакет из одной подсети (10.100.10.0/24) попадает в другую (10.100.11.0/24)?
Как обратится к по MAC в другую IP-подсеть?
Вбить в конфиг и сохранить в файл или построить работающую сеть, использующую оборудование и операционные системы реализующие стандартные сетевые технологии?
Как кратко записать маску 255.0.255.0? Например, 255.255.255.0 получаем маску /24, а в вашем случае какая краткая маска получится?
С точки зрения функционала — да.
С точки зрения безопасности, вариант с межсетевым экраном шлюзового типа (железка то есть) проигрывает, потому как для описания правил фильтрации используются IP-адреса, а они могут быть подменены с помощью IP-spoofing. В тоже время применение локального межестевого экрана в технологии back connect лишено указной проблемы, поскольку он настраивается на фильтрацию в криптографически защищенном соединении (туннеле), в котором не возможна подмена данных.
На практике, back connect следует применять, только там где передается информация особой важности, например передача трафика содержащего аутентификационную информацию, или сведения о переводах денежных средств или управляющие воздействия автоматизированных систем управления технологическими процессами (АСУ ТП).
Более приземленным вариантом может быть защита взаимодействия RO DC c полнофункциональными контролерами домена. В некоторых схема high-security все пользователи авторизуются всегда через RO DC, а администрирование происходит на глубоко спрятанных полнофункциональных контролерах.
Проблема. И заключается она в том, что уязвимости в нем не публикуются, хотя это вовсе не значит что их нет. Пример Windows XP.
Довольно подробно описано тут.
А вот это хороший вопрос. Проблема в том, что сетевая служба ожидающая подключение по порту может содержать уязвимости в коде и быть атакована Нарушителем.
Это можно проиллюстрировать на примере с Heartbleed уязвимостью и Web — приложением проводящим авторизацию на примере форм (Web выбран в только в качестве примера, аналогичная схемы может быть актуальна и для других сервисов).
Здесь неуполномоченные пользователи «отсекаются» авторизацией Web-приложения и вроде бы сервис защищен, но Нарушители могут атаковать непосредственно саму сетевую службу (в данном случае ее компонент — OpenSSL). Дабы не бороться с каждой подобной уязвимостью технология back connect позволяет закрыть сам канал атаки.
Наиболее понятным примером будут ошибки в BMC серверов, для которых нет патчей (не в природе, а для данной модели сервера) и из-за которого приходится этот функционал отключать.
То что вы говорите — это пакетный фильтр, который принимает решение о транзите трафика только на основании данных заголовков.
В статье и моих коментах я оперирую правилами межсетевых экранов работающих с анализом состояния (stateful firewall) В них правила фильтрации помимо адресов учитывают состояния например new, established, invalid,… примером межсетевого экрана подобного класса является iptables. Поэтому при описании правил и применялась фраза — «разрешить инициацию соединений из внутренней сети в DMZ».
Оба типа межсетевых экранов применяются на практике. Пакетные фильтры используются на магистралях, где важна скорость. Statefull применяются на уровне сегментов корпоративных сетей, где важна защита от обхода с помощью фрагментации
Back connect — технология защиты межсерверных связей. Пример ее использования — связь с сервера приложений (того, что обслуживает клиентов) с сервером баз данных. Сервер БД в данном случае будет инициатором построения туннелей и соответственно не будет иметь открытых портов by design. Почему это важно?
На практике, случаются случаи когда на защиту с помощью сетевых устройств нельзя положится на 100%. Это могут быть случаи когда:
Другим примером ее использования обеспечение второго контура безопасности для защиты особо важных данных. Про актуальность этих задач можно посмотреть тут.
Это значит что используются исключительно виртуальные машины и между ними нет железных девайсов и сетевых устройств в привычном понимании.
Туннель позволяет не открывать порт на сервере и не делать правила на межсетевом экране (проброс портов). Зачем это нужно ответил в статье.
Нет помойки, есть информация, стоимость которой весьма высока.
Хочу подчеркнуть важный момент. В статье приводятся только одни из возможных вариантов, они не являются единствено возможными.
Если хочется сравнить несколько вариантов по защищенности то это надо делать на моделе угроз.
Если сравнивать варианты по затратам то лучше это делать по стоимости владения (TCO) в 3 или 5 летней перспективе.
Оператор по переводу денежных средств — Банк. И только Банк обязан вам вернуть баблос, все остальные участники процесса могут только поохать.
А вообще в случае беды — учить наизусть ст. 9 161-ФЗ
1. В течение 23 часов 50 минут звонить в КЦ (контакт центр), при этом желательно разговор записать, предупредив об этом сотрудника КЦ и попросить его назвать дату и время звонка.
2. В ходе разговора с КЦ детально описать суть оспариваемой транзакции.
3. После разговора с КЦ написать письменное заявление обязательно указав, что вы хотите что бы Банк вернул вам денежные средства.
4. Ждать ответа банка в течение 30 дней по Российским транзакциям и 60 по международным.
5. Если Банк не ответил то обращаемся в ЦБ.
6. Хуже не будет если написать заявление в полицию по факту кражи.