Главная » Spring » Шифрование внешних определений свойств Spring

0

Проект Jasypt – это замечательная библиотека, упрощающая шифрование. Она обладает широкими возможностями, знакомство

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

Как упоминалось выше, в версии Spring 2.5 появилось простран- ство  имен  context   и  его  элементы  <context:property-placeholder>   и

<context:property-overrider>. Прежде необходимо было настраивать PropertyPlaceholderConfigurer и PropertyOverrideConfigurer как компо- ненты, чтобы получить необходимые функциональные возможности.

Реализация механизмов подстановки переменных-заполнителей и переопределения свойств в библиотеке Jasypt в настоящее время не имеет собственного пространства имен. Поэтому оба механизма, как и в версиях Spring ниже 2.5, должны настраиваться в виде эле- ментов <bean>.

Например, следующий элемент <bean> настраивает механизм под- становки переменных-заполнителей свойств:

<bean  class=

"org.jasypt.spring.properties.EncryptablePropertyPlaceholderConfigurer" p:location="file:///etc/db.properties">

<constructor-arg ref="stringEncrypter" />

</bean>

А следующий элемент <bean> – механизм переопределения свойств:

<bean  class=

"org.jasypt.spring.properties.EncryptablePropertyOverrideConfigurer" p:location="file:///etc/db.properties">

<constructor-arg ref="stringEncrypter" />

</bean>

Независимо от выбранного механизма следует настроить свой- ство location, определяющее местоположение файла свойств. И оба требуют указать в аргументе конструктора объект, реализующий шифрование.

В Jasypt существует понятие строкового шифратора, под которым

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

целей отлично подойдет класс StandardPBEStringEncryptor, входящий в состав библиотеки Jasypt:

<bean id="stringEncrypter" class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor" p:config-ref="environmentConfig" />

Единственное, что необходимо классу StandardPBEStringEncryptor для выполнения своей работы, – это алгоритм и пароль, исполь- зовавшийся при шифровании данных. Если заглянуть в описание класса StandardPBEStringEncryptor, можно увидеть, что он имеет свой- ства algorithm и password. Эти свойства можно было бы определить непосредственно в объявлении компонента stringEncryptor.

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

Вместо настройки пароля непосредственно в конфигурации Spring я настроил свойство config класса StandardPBEStringEncryptor, опреде- лив в нем ссылку на компонент EnvironmentStringPBEConfig. Environment- StringPBEConfig позволяет настраивать параметры шифрования, такие как пароль, в переменных окружения. EnvironmentStringPBEConfig – это обычный компонент, объявленный, как показано ниже:

<bean   id="environmentConfig"   class= "org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig" p:algorithm="PBEWithMD5AndDES" p:passwordEnvName="DB_ENCRYPTION_PWD"  />

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

У кого-то может появиться вопрос, как перемещение пароля в пе- ременную окружения повысит безопасность. Разве злоумышленник не сможет прочитать переменную окружения так же легко, как кон- фигурационный файл Spring? Да, это так. Но суть в том, что эта переменная окружения, как предполагается, будет устанавливаться администратором системы непосредственно перед запуском при-

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

Механизмы импортирования значений свойств компонентов из

внешних источников – это лишь один из способов управления на- стройками, которые желательно держать в тайне и/или необходи- мо изменять после развертывания приложения. Еще один способ решения этих проблем – импортирование целых объектов из JNDI и настройка Spring на извлечение этих объектов в контекст Spring. Этот способ рассматривается в следующем разделе.

Источник:   Уоллс К., Spring в действии. – М.: ДМК Пресс, 2013. – 752 с.: ил.

По теме:

  • Комментарии