ಕೀ ಪಾಸ್ಫ್ರೇಜ್ ತೆಗೆದುಹಾಕಬೇಕೇ ಅಥವಾ ಇಟ್ಟುಕೊಳ್ಳಬೇಕೇ? ನೀವು ರಚಿಸುವ ಪ್ರತಿ
ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡದ ಕೀ ಫೈಲ್ ಅದೇ ರಹಸ್ಯವನ್ನು ದುರ್ಬಲ ರಕ್ಷಣೆಯ ಹಿಂದೆ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಪರಿವರ್ತಿಸುವ ಮೊದಲು ವಿಶ್ರಾಂತಿಯಲ್ಲಿನ ಅಪಾಯವನ್ನು ಹೋಲಿಸಿ ಮತ್ತು ಅದು ಏನನ್ನು ರದ್ದುಗೊಳಿಸುವುದಿಲ್ಲ ಎಂದು ತಿಳಿಯಿರಿ.
ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಖಾಸಗಿ ಕೀ ಮತ್ತು ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡದ ಕೀ ಒಂದೇ ಕೀ ವಸ್ತುವನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಪರಿವರ್ತನೆ ಹೊಸ ಗುರುತನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ, VPN ಖಾತೆಯನ್ನು ಮರುಹೊಂದಿಸುವುದಿಲ್ಲ ಮತ್ತು ಹಳೆಯ ಫೈಲ್ ಅನ್ನು ಅಮಾನ್ಯಗೊಳಿಸುವುದಿಲ್ಲ. ಅದು ಎರಡನೇ ಪ್ರತಿಯನ್ನು ಬರೆಯುತ್ತದೆ, ಮತ್ತು ಆ ಪ್ರತಿ ಬೇರೆ ವಿಶ್ರಾಂತಿ ಅಪಾಯವನ್ನು ಹೊಂದಿರುತ್ತದೆ.
ಈ ವಿನಿಮಯ ಲಾಭದಾಯಕವೇ ಎಂಬುದು ಫೈಲ್ ಎಲ್ಲಿ ಇರುತ್ತದೆ ಮತ್ತು ಯಾರು ಅದನ್ನು ಓದಬಹುದು ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ.
ಪರಿವರ್ತನೆ ನಿಜವಾಗಿ ಏನನ್ನು ಬದಲಿಸುತ್ತದೆ
ಪರಿವರ್ತನೆಯ ಮೊದಲು, ಕೀಯನ್ನು ನಿರ್ವಾಹಕರು ಒದಗಿಸುವ ಪಾಸ್ಫ್ರೇಜ್ ರಕ್ಷಿಸುತ್ತದೆ. ಪರಿವರ್ತನೆಯ ನಂತರ, ಫೈಲ್ಸಿಸ್ಟಂ ಅನುಮತಿಗಳು ಮತ್ತು ಫೈಲ್ ಸುತ್ತಲಿನ ಯಾವುದೇ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ ಅದನ್ನು ರಕ್ಷಿಸುತ್ತದೆ. ಗೂಢಲಿಪೀಕರಣ ಬದಲಾಗಿಲ್ಲ; ಆಕ್ರಮಣಕಾರರು ಮತ್ತು ಕೀಯ ನಡುವೆ ನಿಂತಿರುವ ವಸ್ತುಗಳ ಸಂಖ್ಯೆ ಬದಲಾಗಿದೆ. ಅದೇ ಸಂಪೂರ್ಣ ಹೋಲಿಕೆ.
ಒಂದು ಕೋಷ್ಟಕ ವ್ಯತ್ಯಾಸವನ್ನು ಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತದೆ.
| Form | What protects it | How it fails |
|---|---|---|
| Encrypted key | A passphrase plus file access | Weak passphrase, or an offline attack on the file |
| Unencrypted key | File permissions and host security only | Any reader copies it silently |
ಯಾವುದೇ ರೂಪ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೆಚ್ಚು ಸುರಕ್ಷಿತವಲ್ಲ. ಅವು ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ, ಮತ್ತು ಆ ಮಾರ್ಗಗಳಲ್ಲಿ ಒಂದೇ ಒಂದು ಲಾಗ್ ನಮೂದನ್ನು ಬಿಡುತ್ತದೆ.
ಪಾಸ್ಫ್ರೇಜ್ ಇಟ್ಟುಕೊಳ್ಳುವುದು ಯಾವಾಗ ಉತ್ತಮ
ಬೆಂಬಲಿತ ಕ್ಲೈಂಟ್ ಪಾಸ್ಫ್ರೇಜ್ಗಾಗಿ ಕೇಳಬಹುದಾದರೆ ಅಥವಾ ಅನುಮೋದಿತ ರಹಸ್ಯ ಭಂಡಾರದಿಂದ ತರಬಹುದಾದರೆ, ಪರಿವರ್ತನೆ ಏನನ್ನೂ ಖರೀದಿಸುವುದಿಲ್ಲ. ನೀವು ಒಂದು ಪ್ರತಿ, ಒಂದು ರಕ್ಷಣಾ ಗಡಿ ಮತ್ತು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಒಂದು ಕಡಿಮೆ ಫೈಲ್ ಇಟ್ಟುಕೊಳ್ಳುತ್ತೀರಿ. PEM ಕೀಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಹೆಚ್ಚಿನ VPN ಕ್ಲೈಂಟ್ಗಳು ಇದನ್ನು ಮಾಡಬಹುದು.
ತಂಡವು ಕೀಯನ್ನು ಹಂಚಿಕೊಂಡಾಗಲೂ ಪರಿವರ್ತನೆ ತಪ್ಪು ಹೆಜ್ಜೆ. ಹಂಚಿಕೊಂಡ ಹೋಸ್ಟ್ನಲ್ಲಿ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡದ ಫೈಲ್ ಶೆಲ್ ಪ್ರವೇಶವಿರುವ ಯಾರಾದರೂ ನಕಲಿಸಬಹುದಾದ ರುಜುವಾತಾಗುತ್ತದೆ.
ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡದ ಪ್ರತಿ ಯಾವಾಗ ಸಮರ್ಥನೀಯ
ಕೆಲವು ಸೇವೆಗಳು ಕೇಳಲಾರವು, ಕೆಲವು ಕಂಟೇನರ್ಗಳು ರಹಸ್ಯಗಳನ್ನು ಓದಲು-ಮಾತ್ರ ಆರೋಹಿಸುತ್ತವೆ, ಮತ್ತು ಕೆಲವು ಸಾಧನಗಳು ಬೂಟ್ನಲ್ಲಿ ಸಂವಾದಾತ್ಮಕ ಮಾರ್ಗವಿಲ್ಲದೆ ಕೀ ಫೈಲ್ ಓದುತ್ತವೆ. ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಸರಿಯಾಗಿ ಸೀಮಿತಗೊಳಿಸಿದ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡದ ಕೀ ಬೆಂಬಲಿತ ವಿನ್ಯಾಸವಾಗಿರಬಹುದು. ಸಮರ್ಥನೆ ಪರಿಸರ, ಅನುಕೂಲವಲ್ಲ.
ಫೈಲ್ ಅನ್ನು ಯಾರು ಓದಬಹುದು ಮತ್ತು ಏಕೆ ಎಂದು ನೀವು ಹೇಳಲಾಗದಿದ್ದರೆ, ಉತ್ತರ ಇಲ್ಲ.
ಆಜ್ಞೆ ಮತ್ತು ಅದರ ಹರಿತ ಅಂಚುಗಳು
OpenSSL 3.5 ಬೆಂಬಲಿಸುವ ಫೈಲ್-ಆಧಾರಿತ ಕೀಗೆ, pkey ಉಲ್ಲೇಖ ಪಾಸ್ಫ್ರೇಜ್ ತೆಗೆದುಹಾಕುವಿಕೆ ಮತ್ತು ಇನ್ಪುಟ್ ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿದ್ದಾಗ ಮತ್ತು ಪಾಸ್ವರ್ಡ್ ಮೂಲವನ್ನು ಒದಗಿಸದಿದ್ದಾಗ ಸಂವಾದಾತ್ಮಕ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಕನಿಷ್ಠ ರೂಪ ಚಿಕ್ಕದಾಗಿದೆ, ಮತ್ತು ಅದನ್ನು ಅಜಾಗರೂಕತೆಯಿಂದ ಚಲಾಯಿಸುವುದು ಸುಲಭ.
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemಮೂರು ಹರಿತ ಅಂಚುಗಳು. ಔಟ್ಪುಟ್ ಫೈಲ್ I/O ಪರಮಾಣು ನಯವಲ್ಲ, ಆದ್ದರಿಂದ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಔಟ್ಪುಟ್ ಮಾರ್ಗವು ಬರವಣಿಗೆಯ ಮಧ್ಯದಲ್ಲಿ ಕಡಿತಗೊಳ್ಳಬಹುದು. ಇನ್ಪುಟ್ ಮಾರ್ಗವನ್ನು ಔಟ್ಪುಟ್ ಆಗಿ ಬಳಸಬೇಡಿ, ಮತ್ತು ಏಕೈಕ ರಕ್ಷಿತ ಪ್ರತಿಯ ಮೇಲೆ ಪ್ರಯೋಗ ಮಾಡಬೇಡಿ. ಪಾಸ್ಫ್ರೇಜ್ ಅನ್ನು ಕಮಾಂಡ್ ಲೈನ್ನಲ್ಲಿ ಅಲ್ಲ, ಪ್ರಾಂಪ್ಟ್ನಲ್ಲಿ ನಮೂದಿಸಿ, ಅಲ್ಲಿ ಅದು ಶೆಲ್ ಇತಿಹಾಸಕ್ಕೆ ಸೇರುತ್ತದೆ.
ಯಾವುದೇ VPN ಸಂರಚನೆಯನ್ನು ಬದಲಿಸುವ ಮೊದಲು ಫಲಿತಾಂಶವನ್ನು ಪರಿಶೀಲಿಸಿ: openssl pkey -in new-private-key.pem -pubout ಮೊದಲು ನೀವು ಹೊಂದಿದ್ದ ಅದೇ ಸಾರ್ವಜನಿಕ ಕೀಯನ್ನು ಮುದ್ರಿಸಬೇಕು.
ಪರಿವರ್ತನೆ ಏನನ್ನು ಮಾಡುವುದಿಲ್ಲ
ಅದು ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಪ್ರತಿಯನ್ನು ರದ್ದುಗೊಳಿಸುವುದಿಲ್ಲ, ಅದು ನೀವು ಎಲ್ಲಿ ಬಿಟ್ಟರೂ ಇನ್ನೂ ಇದೆ. ಅದು VPN ಖಾತೆಯ ಪಾಸ್ವರ್ಡ್ ಅಥವಾ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಈಗಾಗಲೇ ಸಂಭವಿಸಿದ ಒಡ್ಡುವಿಕೆಯನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ. ಕೀ ಸೋರಿಕೆಯಾದರೆ, ಪರಿಹಾರ ಬದಲಾವಣೆ ಮತ್ತು ಸರ್ವರ್-ಬದಿಯ ಹಿಂಪಡೆಯುವಿಕೆ, ಸ್ಥಳೀಯ ಸ್ವರೂಪ ಬದಲಾವಣೆಯಲ್ಲ.
ಮಧ್ಯಂತರ ಫೈಲ್ ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅಳಿಸಿ, ಮತ್ತು ನೀವು ಅಳಿಸುವ ಮಾರ್ಗವು ನೀವು ರಚಿಸಿದ ಮಾರ್ಗವೇ ಎಂದು ಖಚಿತಪಡಿಸಿ.