17 сентября, вторник 01:07
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Оцените нашу систему "Интернет-банк"

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • #61
    2 ALL
    Предполагаю, что спор уходит куда-то вбок. Попробую сформулировать свои мысли по поводу безопасности в ИБ вообще.
    Рассмотрим толстого клиента. Что имеется:
    1. ПО, полученное от производителя или банка
    2. Компьютер на котором все работает
    3. Носитель ключа
    4. Транспортная среда.
    Как обеспечить безопасность.
    1. ПО должно быть trusted, то есть получено из рук поставщика или работника банка.
    2. Компьютер должен быть чист от троянов
    3. Ключ храниться надежно
    4. При транспортировке информация подписана и закодирована
    5. Все это прописано в договоре.
    Простота возникает из-за разделения процесса установки ПО от процесса его эксплуатации, процесса обработки документа от процесса транспортировки и из-за локализации критических процессов и информации на компьютере клиента и сервере банка.
    В ИБ возникает ситуация в которой процесс "установки" ПО происходит при каждом сеансе работы, обработка и транспортировка производится одновременно, а сам сеанс работы совмешен с пересылкой информации. Из за такой наворченности по сравнению с предыдущей схемой (толстый клиент) возникает необходимость комплексной защиты. Например постоянной верификации загружаемого ПО, контроль попыток атак на компьютер в течении сеанса работы (ключи - то в памяти, а труба IP протокола подключена в сеть), и т.д. и т.п. При этом возлагать на пользователя задачи проверки fingerprint`ов, установки сертификатов с проверкой их адекватности и отслеживания истинных адресов серверов это не просто не гуманно, а слегка туповато. Отсюда все проблемы про которые пишут критики.
    В заключении скажу, что пока не видел ни одной системы ИБ, в которой эти вопросы были бы до конца решены.

    С уважением
    Алексей.

    Комментарий


    • #62
      Alexei Volchkov
      Есть предложение переформулировать
      При транспортировке информация подписана и закодирована
      как:

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


      если уж мы решили не употреблять политически некорректных выражений "электронная цифровая подпись" и "шифрование"

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

      Выход есть: сертифицированное по самое "небалуй" всеми возможными ведомствами (нашими и международными) специализироованное устройство с клавиатурой, экраном, ethernet/RS232/USB-соской и дыркой для подключения ключевого носителя, получаемое в банке в опечатаннном виде. Останется только решить проблему с вводом экспортированной из бухгалтерской программы клиента информации...

      p.s. В каждой шутке есть доля шутки.
      Earl Vlad Drakula. ///

      Комментарий


      • #63
        Очень пользительными для систем ИБ могли-бы стать HSM(HardwareSecureModule) - выполняющие все необходимые крипто-операции, и хранящие секретный ключ в таком случае можно уже не опасаться, что кто-то украдет секретный ключ и спать спокойно

        Комментарий


        • #64
          Впрочем, все равно клиенту придется хотя бы фокусировать свой мутный взор на окошке с информацией о подписи аплета, что проблематично ...
          Это как раз проблема решаемая: клиент ставит галочку в поле (всегда доверять подписи данного (XXX) производителя) и в дальнейшем, на данном сайте его объекты выводятся без ругательств.
          После этого любой новый запрос сертификата на исполнение кода следует рассматривать как опасный сигнал и внимательно рассматривать.

          Так им клиентам, гораздо проще будет.

          Комментарий


          • #65
            GeC
            могли-бы стать HSM(HardwareSecureModule)
            Таки есть уже такое Приличные чиповые карты производят криптотоперации "на борту", не выводя ключ за пределы себя. Есть i-button со встроенной java-машиной, куда можно запихать аплет вместе с ключом и ставить подпись путем запихивания данных туда с полученим подписи на выходе. Уже давно есть плата "Криптон", ключи в которую грузятся до загрузки ОС. Есть HSM для процессинга пластика, есть железо для SWIFT. Проблема одна: все эти штучки должны уметь своими средствами показывать пользователю, что именно они подписывают. Иначе в программе юзеру можно показать одно, а в HSM на подпись отправить совсем другое
            Earl Vlad Drakula. ///

            Комментарий


            • #66
              Komlin
              Это как раз проблема решаемая: клиент ставит галочку в поле (всегда доверять подписи данного (XXX) производителя) и в дальнейшем, на данном сайте его объекты выводятся без ругательств.
              Не очень понял. Производитель дает новую версию, а я об этом даже не узнаю? Ведь он может подписать "bugged"-версию, выложить ее временно, упереть мой ключ, потом вернуть старую, нормальную. А я об этом и знать не буду. Нехорошо
              Earl Vlad Drakula. ///

              Комментарий


              • #67
                Поэтому я и считаю, что производитель должен быть со стороны или должна быть независимая подпись сертификатора.

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

                Комментарий

                Пользователи, просматривающие эту тему

                Свернуть

                Присутствует 1. Участников: 0, гостей: 1.

                Обработка...
                X