Thank you for reading this post, don't forget to subscribe!

MongoDB (или про­сто Mongo) – это доку­мен­то­ори­ен­ти­ро­ван­ная систе­ма управ­ле­ния база­ми дан­ных, кото­рая исполь­зу­ет­ся для хра­не­ния инфор­ма­ции во мно­гих совре­мен­ных веб-при­ло­же­ни­ях. Крайне важ­но, что­бы лица, ответ­ствен­ные за управ­ле­ние базой дан­ных Mongo (впро­чем, это каса­ет­ся любой СУБД), при­дер­жи­ва­лись пере­до­вых мето­дов обес­пе­че­ния без­опас­но­сти – это поз­во­ля­ет избе­жать поте­ри дан­ных в слу­чае ава­рии, предот­вра­тить их попа­да­ние в руки зло­умыш­лен­ни­ков и т.п.

Авто­ри­за­ция и аутен­ти­фи­ка­ция – клю­че­вые кон­цеп­ции, име­ю­щие реша­ю­щее зна­че­ние для пони­ма­ния без­опас­но­сти базы дан­ных. Эти поня­тия похо­жи, но вы долж­ны пом­нить, что они зна­чат и чем имен­но отли­ча­ют­ся. Аутен­ти­фи­ка­ция – это про­цесс, кото­рый под­твер­жда­ет, что поль­зо­ва­тель или кли­ент дей­стви­тель­но явля­ют­ся теми, кем они себя назы­ва­ют. Авто­ри­за­ция же под­ра­зу­ме­ва­ет уста­нов­ку пра­вил, опре­де­ля­ю­щих, какие дей­ствия может выпол­нять тот или иной поль­зо­ва­те­ля (или груп­па поль­зо­ва­те­лей) и к каким ресур­сам они могут полу­чить доступ.

Аутентификация в MongoDB

MongoDB име­ет несколь­ко меха­низ­мов аутен­ти­фи­ка­ции поль­зо­ва­те­лей. По умол­ча­нию при­ме­ня­ет­ся меха­низм SCRAM (Salted Challenge Response Authentication Mechanism). SCRAM про­ве­ря­ет ком­би­на­цию учет­ных дан­ных, пред­став­лен­ных поль­зо­ва­те­лем, и срав­ни­ва­ет ее с инфор­ма­ци­ей об этом поль­зо­ва­те­ле, кото­рая извест­на это­му экзем­пля­ру MongoDB. Если какие-либо учет­ные дан­ные поль­зо­ва­те­ля не соот­вет­ству­ют ожи­да­ни­ям базы дан­ных Mongo, меха­низм не аутен­ти­фи­ци­ру­ет тако­го поль­зо­ва­те­ля: он не полу­чит доступ, пока не пред­ста­вит пра­виль­ное имя поль­зо­ва­те­ля, пароль и базу данных.

Так­же мож­но исполь­зо­вать тек­сто­вый файл, кото­рый высту­пит в каче­стве обще­го паро­ля для груп­пы под­клю­чен­ных экзем­пля­ров MongoDB (напри­мер, для набо­ра реплик или чле­нов кла­сте­ра). Этот метод, извест­ный как аутен­ти­фи­ка­ция по клю­че­во­му фай­лу, счи­та­ет­ся мини­маль­ной фор­мой без­опас­но­сти и луч­ше все­го под­хо­дит для сред тести­ро­ва­ния или раз­ра­бот­ки соглас­но доку­мен­та­ции MongoDB.

Для сред про­из­вод­ства с под­держ­кой сег­мен­ти­ро­ва­ния или репли­ка­ции, доку­мен­та­ция MongoDB реко­мен­ду­ет исполь­зо­вать дру­гой меха­низм аутен­ти­фи­ка­ции – x.509. Этот меха­низм под­ра­зу­ме­ва­ет рас­про­стра­не­ние дей­стви­тель­ных сер­ти­фи­ка­тов x.509 (либо само­под­пи­сан­ных, либо полу­чен­ных от сто­рон­не­го цен­тра сер­ти­фи­ка­ции) меж­ду пред­по­ла­га­е­мы­ми чле­на­ми кла­сте­ра или кли­ен­та­ми. Такие сер­ти­фи­ка­ты отли­ча­ют­ся от клю­че­вых фай­лов тем, что каж­дая маши­на полу­ча­ет свой соб­ствен­ный, инди­ви­ду­аль­ный выде­лен­ный сер­ти­фи­кат x.509. Это зна­чит, что сер­ти­фи­кат одной маши­ны будет поле­зен толь­ко для аутен­ти­фи­ка­ции этой маши­ны. Зло­умыш­лен­ни­ки не смо­гут предо­ста­вить сер­ве­ру БД укра­ден­ный сер­ти­фи­кат x.509 и прой­ти аутентификацию.

В мето­де x.509 исполь­зу­ет­ся так назы­ва­е­мая вза­им­ная аутен­ти­фи­ка­ция: то есть когда кли­ент или член кла­сте­ра аутен­ти­фи­ци­ру­ет­ся на сер­ве­ре, сер­вер ана­ло­гич­ным обра­зом аутен­ти­фи­ци­ру­ет­ся на соот­вет­ству­ю­щем кли­ен­те или члене кла­сте­ра. Если кли­ент или член кла­сте­ра попы­та­ет­ся под­клю­чить­ся к сер­ве­ру базы дан­ных с нева­лид­ным сер­ти­фи­ка­том x.509, это будет невоз­мож­но, посколь­ку вза­им­ная про­вер­ка под­лин­но­сти завер­шит­ся неудачно.

Авторизация в MongoDB

Для авто­ри­за­ции MongoDB исполь­зу­ет меха­низм ком­пью­тер­ной без­опас­но­сти, кото­рый назы­ва­ет­ся «управ­ле­ние досту­пом на осно­ве ролей». Вся­кий раз, когда вы созда­е­те поль­зо­ва­те­ля MongoDB, вы може­те предо­ста­вить ему одну или несколь­ко ролей. Имен­но роль опре­де­ля­ет, какие при­ви­ле­гии име­ет этот поль­зо­ва­тель и какие дей­ствия он может выпол­нять в дан­ной БД, кол­лек­ции, набо­ре кол­лек­ций или кла­сте­ре. При­сва­и­вая поль­зо­ва­те­лю какую-либо роль, вы пере­да­е­те ему все при­ви­ле­гии этой роли.

MongoDB име­ет ряд встро­ен­ных ролей, кото­рые предо­став­ля­ют часто исполь­зу­е­мые ком­би­на­ции при­ви­ле­гий. Неко­то­рые роли доступ­ны для каж­дой БД, но боль­шин­ство из них доступ­но толь­ко для базы дан­ных admin, посколь­ку они откры­ва­ют мно­го адми­ни­стра­тив­ных при­ви­ле­гий. Напри­мер, роль readWrite вы може­те при­сво­ить поль­зо­ва­те­лю в любой базе дан­ных – тогда поль­зо­ва­тель смо­жет читать и изме­нять дан­ные, хра­ня­щи­е­ся в соот­вет­ству­ю­щей БД в вашей систе­ме. Одна­ко роль readWriteAnyDatabase, кото­рая поз­во­ля­ет поль­зо­ва­те­лю читать и изме­нять дан­ные в любой базе дан­ных, кро­ме local и config, доступ­на толь­ко в базе дан­ных admin, посколь­ку она предо­став­ля­ет более широ­кие систем­ные привилегии.

Поми­мо встро­ен­ных ролей, Mongo так­же поз­во­ля­ет вам опре­де­лять поль­зо­ва­тель­ские роли, что дает вам еще боль­ший кон­троль над тем, к каким ресур­сам в вашей систе­ме поль­зо­ва­те­ли могут полу­чить доступ. Как и поль­зо­ва­те­ли, роли добав­ля­ют­ся в опре­де­лен­ную базу дан­ных. За исклю­че­ни­ем ролей, создан­ных в базе дан­ных admin, кото­рые могут вклю­чать при­ви­ле­гии для любой БД в систе­ме, при­ви­ле­гии поль­зо­ва­тель­ских ролей при­ме­ня­ют­ся толь­ко к той базе дан­ных, в кото­рой эта роль была созда­на. С уче­том ска­зан­но­го, роль может вклю­чать в свое опре­де­ле­ние одну или несколь­ко суще­ству­ю­щих ролей, а так­же может насле­до­вать при­ви­ле­гии от дру­гих ролей в той же БД.

Бла­го­да­ря тако­му деталь­но­му кон­тро­лю над при­ви­ле­ги­я­ми поль­зо­ва­те­лей вы може­те настро­ить спе­ци­аль­ных выде­лен­ных поль­зо­ва­те­лей для выпол­не­ния опре­де­лен­ных функ­ций (напри­мер, создать адми­ни­стра­то­ра кла­сте­ра для управ­ле­ния набо­ра­ми реплик и сег­мен­ти­ро­ван­ны­ми кла­сте­ра­ми) или адми­ни­стра­то­ра для созда­ния и управ­ле­ния поль­зо­ва­те­ля­ми и поль­зо­ва­тель­ски­ми роля­ми. Подоб­ная стра­те­гия управ­ле­ния поль­зо­ва­те­ля­ми так­же может повы­сить без­опас­ность вашей систе­мы, посколь­ку сокра­ща­ет коли­че­ство поль­зо­ва­те­лей с широ­ки­ми привилегиями.