ಕೋರ್ಸ್‌ಗೆ ಹೊಸ ದಾಖಲಾತಿಯ ಪ್ರಾರಂಭದ ನಿರೀಕ್ಷೆಯಲ್ಲಿ ನಿಮಗಾಗಿ ಉಪಯುಕ್ತ ಲೇಖನದ ಅನುವಾದವನ್ನು ನಾವು ಸಿದ್ಧಪಡಿಸಿದ್ದೇವೆ.
ಪಾರದರ್ಶಕ ಡೇಟಾ ಎನ್‌ಕ್ರಿಪ್ಶನ್ (ಟಿಡಿಇ) ಕಾಣಿಸಿಕೊಂಡಿದೆ ಮತ್ತು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ MySQL. ಆದರೆ ಇದು ಹುಡ್ ಅಡಿಯಲ್ಲಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಸರ್ವರ್‌ನಲ್ಲಿ TDE ಯಾವ ಪರಿಣಾಮವನ್ನು ಬೀರುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನೀವು ಎಂದಾದರೂ ಯೋಚಿಸಿದ್ದೀರಾ? ಈ ಲೇಖನಗಳ ಸರಣಿಯಲ್ಲಿ ನಾವು TDE ಆಂತರಿಕವಾಗಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ. ಯಾವುದೇ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಕೆಲಸ ಮಾಡಲು ಇದು ಅಗತ್ಯವಿರುವುದರಿಂದ ಕೀ ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ. ನಂತರ MySQL/MySQL ಗಾಗಿ ಪರ್ಕೋನಾ ಸರ್ವರ್‌ನಲ್ಲಿ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು MySQL ಗಾಗಿ ಪರ್ಕೋನಾ ಸರ್ವರ್ ಯಾವ ಹೆಚ್ಚುವರಿ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿದೆ ಎಂಬುದನ್ನು ನಾವು ಹತ್ತಿರದಿಂದ ನೋಡುತ್ತೇವೆ.
MySQL ಕೀರಿಂಗ್
ಕೀರಿಂಗ್ ಎನ್ನುವುದು ಸ್ಥಳೀಯ ಫೈಲ್‌ನಲ್ಲಿ (keyring_file) ಅಥವಾ ರಿಮೋಟ್ ಸರ್ವರ್‌ನಲ್ಲಿ (ಹಶಿಕಾರ್ಪ್ ವಾಲ್ಟ್‌ನಂತಹ) ಕೀಗಳನ್ನು ಪ್ರಶ್ನಿಸಲು, ರಚಿಸಲು ಮತ್ತು ಅಳಿಸಲು ಸರ್ವರ್‌ಗೆ ಅನುಮತಿಸುವ ಪ್ಲಗಿನ್‌ಗಳಾಗಿವೆ. ಅವುಗಳ ಮರುಪಡೆಯುವಿಕೆಯನ್ನು ವೇಗಗೊಳಿಸಲು ಕೀಗಳನ್ನು ಯಾವಾಗಲೂ ಸ್ಥಳೀಯವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ.
ಪ್ಲಗಿನ್‌ಗಳನ್ನು ಎರಡು ವರ್ಗಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು:
- ಸ್ಥಳೀಯ ಸಂಗ್ರಹಣೆ. ಉದಾಹರಣೆಗೆ, ಸ್ಥಳೀಯ ಫೈಲ್ (ನಾವು ಇದನ್ನು ಫೈಲ್ ಆಧಾರಿತ ಕೀರಿಂಗ್ ಎಂದು ಕರೆಯುತ್ತೇವೆ).
- ರಿಮೋಟ್ ಸಂಗ್ರಹಣೆ. ಉದಾಹರಣೆಗೆ, ವಾಲ್ಟ್ ಸರ್ವರ್ (ನಾವು ಇದನ್ನು ಸರ್ವರ್ ಆಧಾರಿತ ಕೀರಿಂಗ್ ಎಂದು ಕರೆಯುತ್ತೇವೆ).
ಈ ಪ್ರತ್ಯೇಕತೆಯು ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ ವಿವಿಧ ರೀತಿಯ ಸಂಗ್ರಹಣೆಯು ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುತ್ತದೆ, ಕೀಗಳನ್ನು ಸಂಗ್ರಹಿಸುವಾಗ ಮತ್ತು ಹಿಂಪಡೆಯುವಾಗ ಮಾತ್ರವಲ್ಲದೆ ಅವುಗಳನ್ನು ಚಾಲನೆ ಮಾಡುವಾಗಲೂ ಸಹ.
ಫೈಲ್ ಸಂಗ್ರಹಣೆಯನ್ನು ಬಳಸುವಾಗ, ಪ್ರಾರಂಭದ ನಂತರ, ಸಂಗ್ರಹಣೆಯ ಸಂಪೂರ್ಣ ವಿಷಯಗಳನ್ನು ಸಂಗ್ರಹಕ್ಕೆ ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ: ಕೀ ಐಡಿ, ಕೀ ಬಳಕೆದಾರ, ಕೀ ಪ್ರಕಾರ ಮತ್ತು ಕೀ ಸ್ವತಃ.
ಸರ್ವರ್-ಆಧಾರಿತ ಸ್ಟೋರ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ (ಉದಾಹರಣೆಗೆ ವಾಲ್ಟ್ ಸರ್ವರ್), ಪ್ರಾರಂಭದಲ್ಲಿ ಕೀ ಐಡಿ ಮತ್ತು ಕೀ ಬಳಕೆದಾರರನ್ನು ಮಾತ್ರ ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಎಲ್ಲಾ ಕೀಗಳನ್ನು ಪಡೆಯುವುದು ಪ್ರಾರಂಭವನ್ನು ನಿಧಾನಗೊಳಿಸುವುದಿಲ್ಲ. ಕೀಲಿಗಳನ್ನು ಸೋಮಾರಿಯಾಗಿ ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ. ಅಂದರೆ, ಕೀಲಿಯು ನಿಜವಾಗಿ ಅಗತ್ಯವಿದ್ದಾಗ ಮಾತ್ರ ವಾಲ್ಟ್‌ನಿಂದ ಲೋಡ್ ಆಗುತ್ತದೆ. ಒಮ್ಮೆ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ನಂತರ, ಕೀಲಿಯನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಇದರಿಂದ ಭವಿಷ್ಯದಲ್ಲಿ ವಾಲ್ಟ್ ಸರ್ವರ್‌ಗೆ TLS ಸಂಪರ್ಕಗಳ ಮೂಲಕ ಅದನ್ನು ಪ್ರವೇಶಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಮುಂದೆ, ಪ್ರಮುಖ ಅಂಗಡಿಯಲ್ಲಿ ಯಾವ ಮಾಹಿತಿ ಇದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.
ಪ್ರಮುಖ ಮಾಹಿತಿಯು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:
- ಕೀ ಐಡಿ - ಕೀ ಗುರುತಿಸುವಿಕೆ, ಉದಾಹರಣೆಗೆ:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - ಕೀ ಪ್ರಕಾರ - ಬಳಸಿದ ಗೂಢಲಿಪೀಕರಣ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಆಧರಿಸಿ ಪ್ರಮುಖ ಪ್ರಕಾರ, ಸಂಭವನೀಯ ಮೌಲ್ಯಗಳು: "AES", "RSA" ಅಥವಾ "DSA".
- ಕೀ ಉದ್ದ — ಬೈಟ್‌ಗಳಲ್ಲಿ ಕೀ ಉದ್ದ, AES: 16, 24 ಅಥವಾ 32, RSA 128, 256, 512 ಮತ್ತು DSA 128, 256 ಅಥವಾ 384.
- ಬಳಕೆದಾರ - ಕೀಲಿಯ ಮಾಲೀಕರು. ಕೀಲಿಯು ಸಿಸ್ಟಮ್ ಆಗಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ, ಮಾಸ್ಟರ್ ಕೀ, ನಂತರ ಈ ಕ್ಷೇತ್ರವು ಖಾಲಿಯಾಗಿದೆ. keyring_udf ಬಳಸಿ ಕೀಲಿಯನ್ನು ರಚಿಸಿದರೆ, ಈ ಕ್ಷೇತ್ರವು ಕೀಲಿಯ ಮಾಲೀಕರನ್ನು ಗುರುತಿಸುತ್ತದೆ.
- ಕೀ ಸ್ವತಃ
ಕೀಲಿಯನ್ನು ಜೋಡಿಯಿಂದ ಅನನ್ಯವಾಗಿ ಗುರುತಿಸಲಾಗಿದೆ: key_id, ಬಳಕೆದಾರ.
ಕೀಲಿಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ಅಳಿಸುವಲ್ಲಿ ವ್ಯತ್ಯಾಸಗಳಿವೆ.
ಫೈಲ್ ಸಂಗ್ರಹಣೆ ವೇಗವಾಗಿದೆ. ಕೀ ಸ್ಟೋರ್ ಒಮ್ಮೆ ಫೈಲ್ಗೆ ಕೀಲಿಯನ್ನು ಬರೆಯುತ್ತಿದೆ ಎಂದು ನೀವು ಭಾವಿಸಬಹುದು, ಆದರೆ ಇಲ್ಲ, ಇಲ್ಲಿ ಹೆಚ್ಚಿನವು ನಡೆಯುತ್ತಿದೆ. ಫೈಲ್ ಸಂಗ್ರಹಣೆಯ ಮಾರ್ಪಾಡು ಮಾಡಿದಾಗ, ಎಲ್ಲಾ ವಿಷಯಗಳ ಬ್ಯಾಕಪ್ ನಕಲನ್ನು ಮೊದಲು ರಚಿಸಲಾಗುತ್ತದೆ. ಫೈಲ್ ಅನ್ನು my_biggest_secrets ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಎಂದು ಹೇಳೋಣ, ನಂತರ ಬ್ಯಾಕಪ್ ನಕಲು my_biggest_secrets.backup ಆಗಿರುತ್ತದೆ. ಮುಂದೆ, ಸಂಗ್ರಹವನ್ನು ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ (ಕೀಗಳನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ ಅಥವಾ ಅಳಿಸಲಾಗುತ್ತದೆ) ಮತ್ತು, ಎಲ್ಲವೂ ಯಶಸ್ವಿಯಾದರೆ, ಸಂಗ್ರಹವನ್ನು ಫೈಲ್ಗೆ ಮರುಹೊಂದಿಸಲಾಗುತ್ತದೆ. ಸರ್ವರ್ ವೈಫಲ್ಯದಂತಹ ಅಪರೂಪದ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನೀವು ಈ ಬ್ಯಾಕಪ್ ಫೈಲ್ ಅನ್ನು ನೋಡಬಹುದು. ಮುಂದಿನ ಬಾರಿ ಕೀಗಳನ್ನು ಲೋಡ್ ಮಾಡಿದಾಗ ಬ್ಯಾಕಪ್ ಫೈಲ್ ಅನ್ನು ಅಳಿಸಲಾಗುತ್ತದೆ (ಸಾಮಾನ್ಯವಾಗಿ ಸರ್ವರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದ ನಂತರ).
ಸರ್ವರ್ ಸ್ಟೋರೇಜ್‌ನಲ್ಲಿ ಕೀಲಿಯನ್ನು ಉಳಿಸುವಾಗ ಅಥವಾ ಅಳಿಸುವಾಗ, ಸಂಗ್ರಹಣೆಯು MySQL ಸರ್ವರ್‌ಗೆ “ಕೀಲಿಯನ್ನು ಕಳುಹಿಸು” / “ವಿನಂತಿ ಕೀ ಅಳಿಸುವಿಕೆ” ಆಜ್ಞೆಗಳೊಂದಿಗೆ ಸಂಪರ್ಕಿಸಬೇಕು.
ಸರ್ವರ್ ಆರಂಭಿಕ ವೇಗಕ್ಕೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ. ಉಡಾವಣಾ ವೇಗವು ವಾಲ್ಟ್‌ನಿಂದ ಪ್ರಭಾವಿತವಾಗಿರುತ್ತದೆ ಎಂಬ ಅಂಶದ ಜೊತೆಗೆ, ಪ್ರಾರಂಭದಲ್ಲಿ ವಾಲ್ಟ್‌ನಿಂದ ಎಷ್ಟು ಕೀಗಳನ್ನು ಹಿಂಪಡೆಯಬೇಕು ಎಂಬ ಸಮಸ್ಯೆಯೂ ಇದೆ. ಸಹಜವಾಗಿ, ಇದು ಸರ್ವರ್ ಸಂಗ್ರಹಣೆಗೆ ವಿಶೇಷವಾಗಿ ಮುಖ್ಯವಾಗಿದೆ. ಪ್ರಾರಂಭದಲ್ಲಿ, ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾದ ಟೇಬಲ್‌ಗಳು/ಟೇಬಲ್‌ಸ್ಪೇಸ್‌ಗಳಿಗೆ ಯಾವ ಕೀ ಅಗತ್ಯವಿದೆ ಎಂಬುದನ್ನು ಸರ್ವರ್ ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ಸಂಗ್ರಹಣೆಯಿಂದ ಕೀಲಿಯನ್ನು ವಿನಂತಿಸುತ್ತದೆ. ಮಾಸ್ಟರ್ ಕೀ ಎನ್‌ಕ್ರಿಪ್ಶನ್‌ನೊಂದಿಗೆ "ಕ್ಲೀನ್" ಸರ್ವರ್‌ನಲ್ಲಿ, ಒಂದು ಮಾಸ್ಟರ್ ಕೀ ಇರಬೇಕು, ಅದನ್ನು ಶೇಖರಣೆಯಿಂದ ಹಿಂಪಡೆಯಬೇಕು. ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಕೀಗಳು ಬೇಕಾಗಬಹುದು, ಉದಾಹರಣೆಗೆ, ಬ್ಯಾಕಪ್ ಸರ್ವರ್ ಪ್ರಾಥಮಿಕ ಸರ್ವರ್‌ನಿಂದ ಬ್ಯಾಕಪ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತಿರುವಾಗ. ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಮಾಸ್ಟರ್ ಕೀಲಿಯ ತಿರುಗುವಿಕೆಯನ್ನು ಒದಗಿಸಬೇಕು. ಭವಿಷ್ಯದ ಲೇಖನಗಳಲ್ಲಿ ಇದನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿವರಿಸಲಾಗುವುದು, ಆದರೂ ಬಹು ಮಾಸ್ಟರ್ ಕೀಗಳನ್ನು ಬಳಸುವ ಸರ್ವರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ವಿಶೇಷವಾಗಿ ಸರ್ವರ್-ಸೈಡ್ ಕೀ ಸ್ಟೋರ್ ಅನ್ನು ಬಳಸುವಾಗ ಇಲ್ಲಿ ನಾನು ಗಮನಿಸಲು ಬಯಸುತ್ತೇನೆ.
ಈಗ ಕೀರಿಂಗ್_ಫೈಲ್ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಮಾತನಾಡೋಣ. ನಾನು keyring_file ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವಾಗ, ಸರ್ವರ್ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಕೀರಿಂಗ್_ಫೈಲ್ ಬದಲಾವಣೆಗಳನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ನಾನು ಚಿಂತಿಸುತ್ತಿದ್ದೆ. 5.7 ರಲ್ಲಿ, ಫೈಲ್ ಅಂಕಿಅಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ಚೆಕ್ ಅನ್ನು ನಡೆಸಲಾಯಿತು, ಇದು ಆದರ್ಶ ಪರಿಹಾರವಲ್ಲ, ಮತ್ತು 8.0 ರಲ್ಲಿ ಅದನ್ನು SHA256 ಚೆಕ್ಸಮ್ನೊಂದಿಗೆ ಬದಲಾಯಿಸಲಾಯಿತು.
ನೀವು ಮೊದಲ ಬಾರಿಗೆ keyring_file ಅನ್ನು ರನ್ ಮಾಡಿದಾಗ, ಫೈಲ್ ಅಂಕಿಅಂಶಗಳು ಮತ್ತು ಚೆಕ್ಸಮ್ ಅನ್ನು ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ, ಇದು ಸರ್ವರ್‌ನಿಂದ ನೆನಪಿನಲ್ಲಿರುತ್ತದೆ ಮತ್ತು ಬದಲಾವಣೆಗಳು ಹೊಂದಾಣಿಕೆಯಾದರೆ ಮಾತ್ರ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ. ಫೈಲ್ ಬದಲಾದಾಗ, ಚೆಕ್ಸಮ್ ಅನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತದೆ.
ಪ್ರಮುಖ ಕಮಾನುಗಳ ಕುರಿತು ನಾವು ಈಗಾಗಲೇ ಹಲವು ಪ್ರಶ್ನೆಗಳನ್ನು ಒಳಗೊಂಡಿದ್ದೇವೆ. ಆದಾಗ್ಯೂ, ಸಾಮಾನ್ಯವಾಗಿ ಮರೆತುಹೋಗುವ ಅಥವಾ ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಿಕೊಳ್ಳುವ ಮತ್ತೊಂದು ಪ್ರಮುಖ ವಿಷಯವಿದೆ: ಸರ್ವರ್‌ಗಳಾದ್ಯಂತ ಕೀಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದು.
ನಾನು ಹೇಳುವುದು ಏನೆಂದರೆ? ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಸರ್ವರ್ (ಉದಾಹರಣೆಗೆ, ಪರ್ಕೋನಾ ಸರ್ವರ್) ವಾಲ್ಟ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಸ್ಥಳವನ್ನು ಹೊಂದಿರಬೇಕು, ಇದರಲ್ಲಿ ಪರ್ಕೋನಾ ಸರ್ವರ್ ತನ್ನ ಕೀಗಳನ್ನು ಸಂಗ್ರಹಿಸಬೇಕು. ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಉಳಿಸಲಾದ ಪ್ರತಿಯೊಂದು ಮಾಸ್ಟರ್ ಕೀಯು ಅದರ ಗುರುತಿಸುವಿಕೆಯೊಳಗೆ ಪರ್ಕೋನಾ ಸರ್ವರ್‌ನ GUID ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಇದು ಏಕೆ ಮುಖ್ಯ? ನೀವು ಕೇವಲ ಒಂದು ವಾಲ್ಟ್ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿರುವಿರಿ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಪರ್ಕೋನಾ ಸರ್ವರ್‌ಗಳು ಒಂದೇ ವಾಲ್ಟ್ ಸರ್ವರ್ ಅನ್ನು ಬಳಸುತ್ತವೆ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಸಮಸ್ಯೆ ಸ್ಪಷ್ಟವಾಗಿ ತೋರುತ್ತದೆ. ಎಲ್ಲಾ ಪರ್ಕೋನಾ ಸರ್ವರ್‌ಗಳು ಐಡಿ = 1, ಐಡಿ = 2, ಇತ್ಯಾದಿಗಳಂತಹ ಅನನ್ಯ ಗುರುತಿಸುವಿಕೆಗಳಿಲ್ಲದೆಯೇ ಮಾಸ್ಟರ್ ಕೀಯನ್ನು ಬಳಸಿದರೆ, ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳು ಒಂದೇ ಮಾಸ್ಟರ್ ಕೀಯನ್ನು ಬಳಸುತ್ತವೆ. GUID ಒದಗಿಸುವುದು ಸರ್ವರ್‌ಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವಾಗಿದೆ. ಅನನ್ಯ GUID ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದರೆ ಸರ್ವರ್‌ಗಳ ನಡುವೆ ಕೀಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಬಗ್ಗೆ ಏಕೆ ಮಾತನಾಡಬೇಕು? ಮತ್ತೊಂದು ಪ್ಲಗಿನ್ ಇದೆ - keyring_udf. ಈ ಪ್ಲಗಿನ್‌ನೊಂದಿಗೆ, ನಿಮ್ಮ ಸರ್ವರ್ ಬಳಕೆದಾರರು ತಮ್ಮ ಕೀಗಳನ್ನು ವಾಲ್ಟ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಬಹುದು. ಬಳಕೆದಾರರು ಸರ್ವರ್ 1 ನಲ್ಲಿ ಕೀಲಿಯನ್ನು ರಚಿಸಿದಾಗ ಸಮಸ್ಯೆ ಸಂಭವಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಮತ್ತು ನಂತರ ಸರ್ವರ್ 2 ನಲ್ಲಿ ಅದೇ ಐಡಿಯೊಂದಿಗೆ ಕೀಲಿಯನ್ನು ರಚಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಉದಾಹರಣೆಗೆ:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1ನಿರೀಕ್ಷಿಸಿ. ಎರಡೂ ಸರ್ವರ್‌ಗಳು ಒಂದೇ ವಾಲ್ಟ್ ಸರ್ವರ್ ಅನ್ನು ಬಳಸುತ್ತಿವೆ, ಸರ್ವರ್ 2 ನಲ್ಲಿ ಕೀರಿಂಗ್_ಕೀ_ಸ್ಟೋರ್ ಕಾರ್ಯವು ವಿಫಲವಾಗಬೇಕಲ್ಲವೇ? ಕುತೂಹಲಕಾರಿಯಾಗಿ, ನೀವು ಒಂದು ಸರ್ವರ್‌ನಲ್ಲಿ ಅದೇ ರೀತಿ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ನೀವು ದೋಷವನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0ಅದು ಸರಿ, ROB_1 ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ.
ಎರಡನೆಯ ಉದಾಹರಣೆಯನ್ನು ಮೊದಲು ಚರ್ಚಿಸೋಣ. ನಾವು ಮೊದಲೇ ಹೇಳಿದಂತೆ, keyring_vault ಅಥವಾ ಯಾವುದೇ ಇತರ ಕೀರಿಂಗ್ ಪ್ಲಗಿನ್ ಎಲ್ಲಾ ಪ್ರಮುಖ ID ಗಳನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ಹೊಸ ಕೀಲಿಯನ್ನು ರಚಿಸಿದ ನಂತರ, ROB_1 ಅನ್ನು ಸರ್ವರ್ 1 ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಈ ಕೀಲಿಯನ್ನು ವಾಲ್ಟ್‌ಗೆ ಕಳುಹಿಸುವುದರ ಜೊತೆಗೆ, ಕೀಲಿಯನ್ನು ಸಹ ಸಂಗ್ರಹಕ್ಕೆ ಸೇರಿಸಲಾಗುತ್ತದೆ. ಈಗ, ನಾವು ಅದೇ ಕೀಲಿಯನ್ನು ಎರಡನೇ ಬಾರಿ ಸೇರಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, keyring_vault ಕೀಲಿಯು ಸಂಗ್ರಹದಲ್ಲಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ದೋಷವನ್ನು ಎಸೆಯುತ್ತದೆ.
ಮೊದಲ ಪ್ರಕರಣದಲ್ಲಿ ಪರಿಸ್ಥಿತಿ ವಿಭಿನ್ನವಾಗಿದೆ. ಸರ್ವರ್ 1 ಮತ್ತು ಸರ್ವರ್ 2 ಪ್ರತ್ಯೇಕ ಸಂಗ್ರಹಗಳನ್ನು ಹೊಂದಿವೆ. ROB_1 ಅನ್ನು ಸರ್ವರ್ 1 ಮತ್ತು ವಾಲ್ಟ್ ಸರ್ವರ್‌ನಲ್ಲಿನ ಕೀ ಸಂಗ್ರಹಕ್ಕೆ ಸೇರಿಸಿದ ನಂತರ, ಸರ್ವರ್ 2 ನಲ್ಲಿನ ಕೀ ಸಂಗ್ರಹವು ಸಿಂಕ್ ಆಗಿಲ್ಲ. ಸರ್ವರ್ 2 ನಲ್ಲಿನ ಸಂಗ್ರಹದಲ್ಲಿ ಯಾವುದೇ ROB_1 ಕೀ ಇಲ್ಲ. ಹೀಗಾಗಿ, ROB_1 ಕೀಯನ್ನು keyring_key_store ಮತ್ತು Vault ಸರ್ವರ್‌ಗೆ ಬರೆಯಲಾಗುತ್ತದೆ, ಇದು ಹಿಂದಿನ ಮೌಲ್ಯವನ್ನು (!) ಮೇಲ್ಬರಹ ಮಾಡುತ್ತದೆ. ಈಗ ವಾಲ್ಟ್ ಸರ್ವರ್‌ನಲ್ಲಿನ ROB_1 ಕೀ 543210987654321 ಆಗಿದೆ. ಕುತೂಹಲಕಾರಿಯಾಗಿ, ವಾಲ್ಟ್ ಸರ್ವರ್ ಅಂತಹ ಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ಬಂಧಿಸುವುದಿಲ್ಲ ಮತ್ತು ಹಳೆಯ ಮೌಲ್ಯವನ್ನು ಸುಲಭವಾಗಿ ತಿದ್ದಿ ಬರೆಯುತ್ತದೆ.
ನೀವು keyring_udf ಅನ್ನು ಬಳಸುತ್ತಿರುವಾಗ ಮತ್ತು ವಾಲ್ಟ್‌ನಲ್ಲಿ ಕೀಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಯಸಿದಾಗ - ವಾಲ್ಟ್‌ನಲ್ಲಿ ಸರ್ವರ್ ವಿಭಜನೆಯು ಏಕೆ ಮುಖ್ಯವಾಗಬಹುದು ಎಂಬುದನ್ನು ನಾವು ಈಗ ನೋಡಬಹುದು. ವಾಲ್ಟ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಈ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಸಾಧಿಸುವುದು ಹೇಗೆ?
ವಾಲ್ಟ್ ಆಗಿ ವಿಭಜಿಸಲು ಎರಡು ಮಾರ್ಗಗಳಿವೆ. ನೀವು ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ ವಿಭಿನ್ನ ಮೌಂಟ್ ಪಾಯಿಂಟ್‌ಗಳನ್ನು ರಚಿಸಬಹುದು ಅಥವಾ ಒಂದೇ ಮೌಂಟ್ ಪಾಯಿಂಟ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ಮಾರ್ಗಗಳನ್ನು ಬಳಸಬಹುದು. ಉದಾಹರಣೆಗಳೊಂದಿಗೆ ಇದನ್ನು ಉತ್ತಮವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ. ಆದ್ದರಿಂದ ಮೊದಲು ಪ್ರತ್ಯೇಕ ಮೌಂಟ್ ಪಾಯಿಂಟ್‌ಗಳನ್ನು ನೋಡೋಣ:
--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)ಸರ್ವರ್ 1 ಮತ್ತು ಸರ್ವರ್ 2 ವಿಭಿನ್ನ ಮೌಂಟ್ ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಬಳಸುತ್ತಿರುವುದನ್ನು ಇಲ್ಲಿ ನೀವು ನೋಡಬಹುದು. ಮಾರ್ಗಗಳನ್ನು ವಿಭಜಿಸುವಾಗ, ಸಂರಚನೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಎರಡೂ ಸರ್ವರ್‌ಗಳು ಒಂದೇ ಮೌಂಟ್ ಪಾಯಿಂಟ್ "ಮೌಂಟ್_ಪಾಯಿಂಟ್" ಅನ್ನು ಬಳಸುತ್ತವೆ, ಆದರೆ ವಿಭಿನ್ನ ಮಾರ್ಗಗಳು. ಈ ಮಾರ್ಗವನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಸರ್ವರ್ 1 ನಲ್ಲಿ ಮೊದಲ ರಹಸ್ಯವನ್ನು ರಚಿಸಿದಾಗ, ವಾಲ್ಟ್ ಸರ್ವರ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ “ಸರ್ವರ್ 1” ಡೈರೆಕ್ಟರಿಯನ್ನು ರಚಿಸುತ್ತದೆ. ಸರ್ವರ್ 2 ಗಾಗಿ ಎಲ್ಲವೂ ಹೋಲುತ್ತದೆ. ನೀವು mount_point/server1 ಅಥವಾ mount_point/server2 ನಲ್ಲಿ ಕೊನೆಯ ರಹಸ್ಯವನ್ನು ಅಳಿಸಿದಾಗ, Vault ಸರ್ವರ್ ಆ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ಸಹ ಅಳಿಸುತ್ತದೆ. ನೀವು ಮಾರ್ಗವನ್ನು ಬೇರ್ಪಡಿಸುವ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಕೇವಲ ಒಂದು ಮೌಂಟ್ ಪಾಯಿಂಟ್ ಅನ್ನು ರಚಿಸಬೇಕು ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಬೇಕು ಇದರಿಂದ ಸರ್ವರ್‌ಗಳು ಪ್ರತ್ಯೇಕ ಮಾರ್ಗಗಳನ್ನು ಬಳಸುತ್ತವೆ. HTTP ವಿನಂತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಮೌಂಟ್ ಪಾಯಿಂಟ್ ಅನ್ನು ರಚಿಸಬಹುದು. CURL ಅನ್ನು ಬಳಸಿಕೊಂಡು ಇದನ್ನು ಈ ರೀತಿ ಮಾಡಬಹುದು:
curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTಎಲ್ಲಾ ಕ್ಷೇತ್ರಗಳು (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನ ನಿಯತಾಂಕಗಳಿಗೆ ಸಂಬಂಧಿಸಿವೆ. ಸಹಜವಾಗಿ, ನೀವು ಅದೇ ರೀತಿ ಮಾಡಲು ವಾಲ್ಟ್ ಉಪಯುಕ್ತತೆಗಳನ್ನು ಬಳಸಬಹುದು. ಆದರೆ ಮೌಂಟ್ ಪಾಯಿಂಟ್ ರಚನೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವುದು ಸುಲಭ. ಈ ಮಾಹಿತಿಯು ನಿಮಗೆ ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ ಮತ್ತು ಈ ಸರಣಿಯ ಮುಂದಿನ ಲೇಖನಗಳಲ್ಲಿ ನಾವು ನಿಮ್ಮನ್ನು ನೋಡುತ್ತೇವೆ.
ಮತ್ತಷ್ಟು ಓದು:
ಮೂಲ: www.habr.com