Чтобы следовать идеологии Security by Design, нужно «заложить» безопасность еще на этапе проектирования системы. В частности, для этого при проектировании архитектуры важно выделить доверенные компоненты, от которых зависит достижение поставленных перед системой целей безопасности. Но как именно их выделить?
Интуитивный вариант, который сразу приходит в голову, — пройтись по всем компонентам и определить, насколько каждая из них заслуживает доверия. Те, что заслуживают больше, объявить доверенными, те, что меньше, — недоверенными. Но в этом случае мы объявим доверенными не те компоненты, которые влияют на достижение целей безопасности, а те, которые уже достаточно хороши, но, возможно, некритичны с точки зрения целей безопасности. Что же тогда делать?
В приключенческих фильмах и книгах мир часто предначертано спасти не опытному герою, заслужившему эту честь, а мальчику-неумехе, на которого такая судьба сваливается нежданно-негаданно. Мальчик-избранный проходит через испытания, взрослеет, наконец, становится достойным своего предназначения и исполняет его.
При выборе доверенных компонент действует схожий принцип: доверенными (trusted) выбирают не те компоненты-герои, которые этого доверия заслуживают изначально, а те, которым «судьбой» (т. е. целями безопасности) «предначертано» такими быть. И затем делают их заслуживающими доверия (или «благонадежными», trustworthy) с помощью анализа кода.
И тут возникает другой вопрос. Допустим, какой-то компоненте «судьбой предначертано» быть доверенной, но она для этого совершенно не годится — например, имеет огромную поверхность атаки и сложную функциональность. Делать такую компоненту «благонадежной» слишком дорого. Как тогда быть?
Пример. За аутентификацию пользователя на сайте отвечает веб-сервер. Сделать его доверенной компонентой из-за огромных размеров практически невозможно. В этом случае лучше создать отдельный сервис аутентификации, который будет решать одну узкую задачу, и вынести его за пределы веб-сервера. Затем сделать этот новый сервис доверенным, а веб-сервер оставить недоверенным. В результате стоимость системы, которая будет гарантированно выполнять заявленные цели безопасности (в данном случае связанные с аутентификацией), останется в пределах разумного.
Пример. Для реализации TLS Terminator в наших решениях мы выбрали компактную библиотеку Mbed TLS. Проверить ее и сделать «доверенной» было намного проще, чем, например, ту же OpenSSL.
Подведем итог. Быть доверенным (trusted) и заслуживающим доверия (trustworthy) — не эквивалентные понятия. Доверие — это вынужденная мера по отношению к компонентам, критичным для безопасности системы. А «благонадежными» они становятся уже после всех проверочных процедур.
Чтобы следовать идеологии Security by Design, нужно «заложить» безопасность еще на этапе проектирования системы. В частности, для этого при проектировании архитектуры важно выделить доверенные компоненты, от которых зависит достижение поставленных перед системой целей безопасности. Но как именно их выделить?
Интуитивный вариант, который сразу приходит в голову, — пройтись по всем компонентам и определить, насколько каждая из них заслуживает доверия. Те, что заслуживают больше, объявить доверенными, те, что меньше, — недоверенными. Но в этом случае мы объявим доверенными не те компоненты, которые влияют на достижение целей безопасности, а те, которые уже достаточно хороши, но, возможно, некритичны с точки зрения целей безопасности. Что же тогда делать?
В приключенческих фильмах и книгах мир часто предначертано спасти не опытному герою, заслужившему эту честь, а мальчику-неумехе, на которого такая судьба сваливается нежданно-негаданно. Мальчик-избранный проходит через испытания, взрослеет, наконец, становится достойным своего предназначения и исполняет его.
При выборе доверенных компонент действует схожий принцип: доверенными (trusted) выбирают не те компоненты-герои, которые этого доверия заслуживают изначально, а те, которым «судьбой» (т. е. целями безопасности) «предначертано» такими быть. И затем делают их заслуживающими доверия (или «благонадежными», trustworthy) с помощью анализа кода.
И тут возникает другой вопрос. Допустим, какой-то компоненте «судьбой предначертано» быть доверенной, но она для этого совершенно не годится — например, имеет огромную поверхность атаки и сложную функциональность. Делать такую компоненту «благонадежной» слишком дорого. Как тогда быть?
Пример. За аутентификацию пользователя на сайте отвечает веб-сервер. Сделать его доверенной компонентой из-за огромных размеров практически невозможно. В этом случае лучше создать отдельный сервис аутентификации, который будет решать одну узкую задачу, и вынести его за пределы веб-сервера. Затем сделать этот новый сервис доверенным, а веб-сервер оставить недоверенным. В результате стоимость системы, которая будет гарантированно выполнять заявленные цели безопасности (в данном случае связанные с аутентификацией), останется в пределах разумного.
Пример. Для реализации TLS Terminator в наших решениях мы выбрали компактную библиотеку Mbed TLS. Проверить ее и сделать «доверенной» было намного проще, чем, например, ту же OpenSSL.
Подведем итог. Быть доверенным (trusted) и заслуживающим доверия (trustworthy) — не эквивалентные понятия. Доверие — это вынужденная мера по отношению к компонентам, критичным для безопасности системы. А «благонадежными» они становятся уже после всех проверочных процедур.
