.jpg)
我想，每個(gè)人心里都清楚，要想授權(quán)最簡(jiǎn)單最簡(jiǎn)單方便，維護(hù)工作量最少，那自然是將所有權(quán)限都授予所有的用戶來(lái)的最簡(jiǎn)單方便了。但是，我們大家肯定也都知道，一個(gè)用戶所用有的權(quán)限越大，那么他給我們的系統(tǒng)所帶來(lái)的潛在威脅也就越大。所以，從安全方面來(lái)考慮的話，權(quán)限自然是授予的越小越好。一個(gè)有足夠安全意識(shí)的管理員在授權(quán)的時(shí)候，都會(huì)只授予必要的權(quán)限，而不會(huì)授予任何多余的權(quán)限。既然我們這一章是專門討論安全的，那么我們現(xiàn)在也就從安全的角度來(lái)考慮如何設(shè)計(jì)一個(gè)更為安全合理的授權(quán)策略。
首先，需要了解來(lái)訪主機(jī)。
由于 MySQL 數(shù)據(jù)庫(kù)登錄驗(yàn)證用戶的時(shí)候是出了用戶名和密碼之外，還要驗(yàn)證來(lái)源主機(jī)。所以我們還需要了解每個(gè)用戶可能從哪些主機(jī)發(fā)起連接。當(dāng)然，我們也可以通過(guò)授權(quán)的時(shí)候直接通過(guò)“%”通配符來(lái)給所有主機(jī)都有訪問(wèn)的權(quán)限，但是這樣作就違背了我們安全策略的原則，帶來(lái)了潛在風(fēng)險(xiǎn)，所以并不可取。尤其是在沒(méi)有局域網(wǎng)的防火墻保護(hù)的情況下，更是不能輕易允許可以從任何主機(jī)登錄的用戶存在。能通過(guò)具體主機(jī)名或者 IP 地址指定的盡量通過(guò)使用具體的主機(jī)名和 IP 地址來(lái)限定來(lái)訪主機(jī)，不能用具體的主機(jī)名或者 IP 地址限定的也需要用盡可能小的通配范圍來(lái)限定。
其次，了解用戶需求。
既然是要做到僅授予必要的權(quán)限，那么我們必須了解每個(gè)用戶所擔(dān)當(dāng)?shù)慕巧?，也就是說(shuō)，我們需要充分了解每個(gè)用戶需要連接到數(shù)據(jù)庫(kù)上完成什么工作。了解該用戶是一個(gè)只讀應(yīng)用的用戶，還是一個(gè)讀寫都有的帳戶；是一個(gè)備份作業(yè)的用戶還是一個(gè)日常管理的帳戶；是只需要訪問(wèn)特定的某個(gè)（或者某幾個(gè)）數(shù)據(jù)庫(kù)（Schema），還是需要訪問(wèn)所有的數(shù)據(jù)庫(kù)。只有了解了需要做什么，才能準(zhǔn)確的了解需要授予什么樣的權(quán)限。因?yàn)槿绻麢?quán)限過(guò)低，會(huì)造成工作無(wú)法正常完成，而權(quán)限過(guò)高，則存在潛在的安全風(fēng)險(xiǎn)。
再次，要為工作分類。
為了做到各司其職，我們需要將需要做的工作分門別類，不同類別的工作使用不同的用戶，做好用戶分離。雖然這樣可能會(huì)帶來(lái)管理成本方面的部分工作量增加，但是基于安全方面的考慮，這部分管理工作量的增加是非常值得的。而且我們所需要做的用戶分離也只是一個(gè)適度的分離。比如將執(zhí)行備份工作、復(fù)制工作、常規(guī)應(yīng)用訪問(wèn)、只讀應(yīng)用訪問(wèn)和日常管理工作分別分理出單獨(dú)的特定帳戶來(lái)授予各自所需權(quán)限。這樣，既可以讓安全風(fēng)險(xiǎn)盡量降低，也可以讓同類同級(jí)別的相似權(quán)限合并在一起，不互相交織在一起。對(duì)于 PROCESS，F(xiàn)ILE 和SUPER 這樣的特殊權(quán)限，僅僅只有管理類帳號(hào)才需要，不應(yīng)該授予其他非管理帳號(hào)。
最后，確保只有絕對(duì)必要者擁有 GRANT OPTION 權(quán)限。
之前在權(quán)限系統(tǒng)介紹的時(shí)候我們已經(jīng)了解到 GRANT OPTION 權(quán)限的特殊性，和擁有該權(quán)限之后的潛在風(fēng)險(xiǎn)，所以在這里也就不再累述了?？傊?，為了安全考慮，擁有 GRANT OPTION權(quán)限的用戶越少越好，盡可能只讓擁有超級(jí)權(quán)限的用戶才擁有 GRANT OPTION 權(quán)限。
?以上就是MySQL訪問(wèn)授權(quán)策略的內(nèi)容，更多相關(guān)內(nèi)容請(qǐng)關(guān)注PHP中文網(wǎng)（www.php.cn）！
.png)
