16 октября, вторник 02:06
Bankir.Ru

Объявление

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

Безопасность в SOA

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

  • Безопасность в SOA

    Вопросы по обеспечению безопасности в сервисно-ориентированной архитектуре.

  • #2
    Риторический вопрос по обеспечению безопасности в сервисно-ориентированной архитектуре.

    Комментарий


    • #3
      У меня такой вопрос: знаете ли вы какую-нибудь организацию, где хоть в одном интерфейсе, реализованном в SOA, сохранялся пользовательский контекст на всех уровнях от ввода данных в исходную систему до их появления в целевой системе? Не просто передавалось имя пользователя в текстовом поле сообщения, а реально все процессы выполнялись под соответствующим пользователем...

      Комментарий


      • #4
        Сообщение от Valentin Nikolaev Посмотреть сообщение
        Вопросы по обеспечению безопасности в сервисно-ориентированной архитектуре.
        А чем собственно опасности SOA отличаются от опасностей иных (не "монолитных") архитектур по Вашему мнению?

        Комментарий


        • #5
          Сообщение от Angl Посмотреть сообщение
          У меня такой вопрос: знаете ли вы какую-нибудь организацию, где хоть в одном интерфейсе, реализованном в SOA, сохранялся пользовательский контекст на всех уровнях от ввода данных в исходную систему до их появления в целевой системе? Не просто передавалось имя пользователя в текстовом поле сообщения, а реально все процессы выполнялись под соответствующим пользователем...
          А зачем это нужно - "...все процессы выполнялись под соответствующим пользователем..."? Разве не достаточно разграничения прав внутри процесса? А может сами процессы продумать более "атомарными" с точки зрения прав, что бы пользователю просто не давать возможность исполнения запрещенного ему процесса?

          Комментарий


          • #6
            Сообщение от IgorL Посмотреть сообщение
            А чем собственно опасности SOA отличаются от опасностей иных (не "монолитных") архитектур по Вашему мнению?
            Краткая справка
            "Безопасность вообще" с точки зрения функционала делится на:
            - Аутентификацию (идентифицировали пользователя) / авторизацию (разделение прав доступа пользователя к операциям)
            - Целостность (никто не подделал данные)
            - Конфиденциальность (данные вызова сервиса не видны неавторизованным людям или серверным процессам)

            Общее соглашение, как это должно вписываться в контракт сервиса, определяется спецификацией WS-Security.

            Также безопасность это одно из "качеств" сервиса, что описывается в спецификации WS-Policy.

            Резюмэ:
            "Безопасность в СОА" просто хорошо структурирована на уровне описания сервисов.
            На уровне реализации она реализуется тем же образом, что и любая "безопасность" в любой другой архитектуре: симметричное/ассиметричное шифрование и т.д.

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

            СОА только делает использование безопасности универсальным и встроенным в описание сервиса.

            Комментарий


            • #7
              Да, но есть еще аспект безопасности данных в момент прохождения по ESB, которая является непременным атрибутом СОА. В традиционных архитектурах нет ESB, соответственно эти специфические проблемы отсутствуют.

              Комментарий


              • #8
                Сообщение от Valentin Kluchnik Посмотреть сообщение
                ....
                Поэтому их "опасность" (я понял вопрос как "потенциальные дырки") на мой взгляд равна "опасностям" способов реализации.
                Т.е. "опасности" цифровой подписи зависят от алгоритма подписи, а не от архитектуры СОА или J2EE.

                СОА только делает использование безопасности универсальным и встроенным в описание сервиса.
                Согласен на 100%. Потому и задал вопрос.

                Комментарий


                • #9
                  Сообщение от Angl Посмотреть сообщение
                  Да, но есть еще аспект безопасности данных в момент прохождения по ESB, которая является непременным атрибутом СОА. В традиционных архитектурах нет ESB, соответственно эти специфические проблемы отсутствуют.
                  А есть еще аспект прохождения данных по сети, по внутренней шине сервера, через драйвер сетевой карты и т.д. В любом из этих мест данные могут быть перехвачены (и даже модифицированы). Надеюсь не предполагается к ESB давать доступ всем пользователям?

                  Комментарий


                  • #10
                    Сообщение от IgorL Посмотреть сообщение
                    А есть еще аспект прохождения данных по сети, по внутренней шине сервера, через драйвер сетевой карты и т.д. В любом из этих мест данные могут быть перехвачены (и даже модифицированы). Надеюсь не предполагается к ESB давать доступ всем пользователям?
                    Обычно пользователь напрямую не работает с ESB. Взаимодействие их с шиной осуществляется через посредничество соответствующих прикладных систем.

                    Комментарий


                    • #11
                      Сообщение от IgorL Посмотреть сообщение
                      А есть еще аспект прохождения данных по сети, по внутренней шине сервера, через драйвер сетевой карты и т.д. В любом из этих мест данные могут быть перехвачены (и даже модифицированы). Надеюсь не предполагается к ESB давать доступ всем пользователям?
                      Современные ESB включают много дополнительной функциональности помимо собственно коммутации веб-сервисов и трансформации интерфейсов. Рассмотрим на примере IBM WS Process Server. Там есть компоненты исполнения BPEL-процессов, ручных задач (к которым кстати таки имеют доступ пользователи), бизнес-правила (аналогично), и т.д. Все эти компоненты хотя и имеют описанный на WSDL интерфейс, общаются внутри ESB по SCA-интерфейсу. Вы полагаете, тут с точки зрения безопасности нечего обсуждать?

                      Комментарий


                      • #12
                        Сообщение от Angl Посмотреть сообщение
                        Современные ESB включают много дополнительной функциональности помимо собственно коммутации веб-сервисов и трансформации интерфейсов. Рассмотрим на примере IBM WS Process Server. Там есть компоненты исполнения BPEL-процессов, ручных задач (к которым кстати таки имеют доступ пользователи), бизнес-правила (аналогично), и т.д.
                        Пользователи имеют доступ к формам ручных задач (если утром брить зеркало, щетина на лице останется в неизменном виде). К бизнес-правилам... возможно, но это должен быть ОЧЕНЬ продвинутый пользователь. Безопасней дать ему возможность выбора (ветвления) по преднаписанным правилам.
                        Сообщение от Angl Посмотреть сообщение
                        Все эти компоненты хотя и имеют описанный на WSDL интерфейс, общаются внутри ESB по SCA-интерфейсу. Вы полагаете, тут с точки зрения безопасности нечего обсуждать?
                        Полагаю, что если правильно спроектировать взаимодействие с пользователем... опасность остается конечно - программист и администратор могут изменить... но при правильной организации они не смогут получить доступ к результатам изменения.

                        Комментарий


                        • #13
                          Сообщение от Angl Посмотреть сообщение
                          Современные ESB включают много дополнительной функциональности помимо собственно коммутации веб-сервисов и трансформации интерфейсов. Рассмотрим на примере IBM WS Process Server. Там есть компоненты исполнения BPEL-процессов, ручных задач (к которым кстати таки имеют доступ пользователи), бизнес-правила (аналогично), и т.д. Все эти компоненты хотя и имеют описанный на WSDL интерфейс, общаются внутри ESB по SCA-интерфейсу. Вы полагаете, тут с точки зрения безопасности нечего обсуждать?
                          Опишу свое мнение, возможно оно не финальное и требует проработки.
                          В WS-Security есть понятие "Ent-to-end message level security".
                          Это требует, что когда есть посредники между потребителем и поставщиком , информация ходит на уровне сообщения защищенная тем способом, которого требует сервис.

                          Обычно это ключи и закодированные (encoded) части сообщения, которые находятся в header'е.
                          Если мы защищаем конфиденщиальность (данные видят только авторизованные люди и процессы), то расшифровать данные может только тот кто обладает ключами расшифровки.
                          Есть 2 варианта:
                          1. Если блок ESB НЕ меняет значение полей сообщения.
                          Обычно это конечный сервис который делает финальную расшифровку.
                          И даже если внутри ESB есть доступ к полям операции - ну получим мы закодированное значение поля объекта - без ключей мы не сможем его расшифровать.

                          2. Если блок ESB меняет значение полей сообщения. Блоку надо:
                          - раскодировать значение
                          - проверить авторизацию: можно ли менять данные под этим пользователем
                          - если да, изменить данные
                          - закодировать обратно тем же ключом

                          У меня кстати вызывает подозрение такой блок ESB, который меняет информацию.

                          Но и в этом случае на выходе из узла у нас будет закодированное поле объекта, пусть и измененное.

                          Итого:
                          1. надо отследить правило передачи информации между всеми блоками в зашифрованном виде.
                          2. при соблюдении этого правила ESB не нарушит принципа "end-to-end message level security".
                          3. ESB часто позиционируется как средство повышения безопасности сервисов: построение дополнительных "сервисов безопасности" в дополнение к простым не-безопасным конечным системам.

                          Комментарий


                          • #14
                            тогда в случае п.2 может применяться только симметричное шифрование?

                            Комментарий

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

                            Свернуть

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

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