ತಾತ್ಕಾಲಿಕ IP ಅನುಮತಿ ಪಟ್ಟಿಯ ಕೊಂಡಿಗಳು: ಅನುದಾನ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಒಪ್ಪುತ್ತದೆ

ಒಂದು ಕ್ಲಿಕ್ ಅನ್ನು ತಾತ್ಕಾಲಿಕ ಫೈರ್ವಾಲ್ ನಿಯಮವಾಗಿ ಬದಲಿಸುವುದು ಅನುಕೂಲಕರ, ಮತ್ತು ಅದು ಯಾರು ಸೇವೆಯನ್ನು ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ಅಧಿಕಾರ ವ್ಯವಸ್ಥೆಯನ್ನೂ ನಿರ್ಮಿಸುತ್ತದೆ. ಅದು ನೀಡುವುದು ವ್ಯಕ್ತಿಯನ್ನಲ್ಲ, ವಿಳಾಸವನ್ನು, ಮತ್ತು ಇಬ್ಬರು ಒಂದೇ NAT ಹಂಚಿಕೊಳ್ಳುವ ಕ್ಷಣದಿಂದ ಈ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯವಾಗುತ್ತದೆ. ಅನುದಾನದ ವ್ಯಾಪ್ತಿಯನ್ನು ಮಿತಿಗೊಳಿಸಿ, ಅದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ದೃಢೀಕರಿಸಿ ಮತ್ತು ಕೊಂಡಿ ನಿರ್ಮಾಣವಾಗುವ ಮೊದಲು ಅವಧಿ ಮುಗಿಯುವಿಕೆಗೆ ಅರ್ಥ ನೀಡಿ. ನಿಮ್ಮ ಮುಂದಿರುವ ನಿರ್ಧಾರ ಎಂದರೆ ಗಡಿಯನ್ನು ಎಲ್ಲಿ ಇರಿಸುವುದು, ಗಡಿ ಇರಬೇಕೇ ಬೇಡವೇ ಎಂಬುದಲ್ಲ.

ಅನುದಾನ ಯಾವ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ

ಅಗತ್ಯದಿಂದ ಪ್ರಾರಂಭಿಸಿ. ಹೆಸರಿಸಿದ ವ್ಯಕ್ತಿ ಸೇವೆಯನ್ನು ತಲುಪಬೇಕಿದ್ದರೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಈಗಾಗಲೇ ಆ ವ್ಯಕ್ತಿಯನ್ನು ದೃಢೀಕರಿಸಿದರೆ, ದೃಢೀಕೃತ ಗೇಟ್‌ವೇ ಗುರುತನ್ನು ಜಾರಿ ಬಿಂದುವಿನಲ್ಲೇ ಇರಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ವಿಳಾಸದ ಸ್ವೀಕೃತಿಯ ಅಗತ್ಯವೇ ಇಲ್ಲ. ಗುರಿ ಬಿಲ್ಡ್ ಏಜೆಂಟ್, ಆಡಳಿತಾತ್ಮಕ ಜಂಪ್ ಪೋರ್ಟ್ ಅಥವಾ ಬಳಕೆದಾರ ಲಾಗಿನ್‌ನಲ್ಲಿ ಭಾಗವಹಿಸಲಾಗದ ಸಾಧನವಾಗಿದ್ದರೆ, ಮಿತವಾದ ವ್ಯಾಪ್ತಿಯ ವಿಳಾಸ ಅನುದಾನವೇ ಲಭ್ಯವಿರುವ ಏಕೈಕ ಪ್ರಾಯೋಗಿಕ ನಿಯಂತ್ರಣವಾಗಿರಬಹುದು.

ಬಳಕೆದಾರರತ್ತ ಮುಖವಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ವಿಳಾಸ ಆಧಾರಿತ ಸ್ವೀಕೃತಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ನಿಜವಾದ ಅಧಿಕಾರ ಸಮಸ್ಯೆಯನ್ನು ಬೇರೆಡೆಗೆ ಸರಿಸುತ್ತದೆ, ಮತ್ತು ನಂತರ ಪೋರ್ಟಲ್ ತಾನು ಎಂದೂ ಮುಚ್ಚದ ಕೊರತೆಗೆ ದೂಷಣೆಯನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತದೆ.

ಸರ್ವರ್‌ನಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಮಿತಿಗೊಳಿಸಿ

ಬ್ರೌಸರ್ ಗಮ್ಯಸ್ಥಾನ, ಪೋರ್ಟ್ ಅಥವಾ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಆಯ್ಕೆ ಮಾಡಬಾರದು. ಪೋರ್ಟಲ್ ಸೇವೆಯನ್ನು ತನ್ನದೇ ದಾಖಲೆಗಳಿಂದ ಪರಿಹರಿಸುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್ ಬದಿಯ ಪರೀಕ್ಷೆಯಿಂದ ಹಕ್ಕನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಇದು OWASP ನ ಅಧಿಕಾರ ಮಾರ್ಗದರ್ಶನ ಪ್ರತಿ ವಿನಂತಿಗೆ ಅನ್ವಯಿಸುವ ಅದೇ ತತ್ವವಾಗಿದೆ. ವಿಳಾಸದ ವ್ಯುತ್ಪತ್ತಿಯೂ ಸಂರಕ್ಷಿತ ಗಡಿಗೆ ಸೇರಿದೆ: ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು ವರದಿ ಮಾಡಿದಾಗ, ಸಂರಚಿತ ಪ್ರಾಕ್ಸಿ ಸರಪಳಿ ಮತ್ತು ಅದರ ದಾಖಲಿತ ಹೆಡರ್ ನಿರ್ವಹಣೆಯನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸಿ. ಸಂದರ್ಶಕ ಒದಗಿಸುವ ಫಾರ್ವರ್ಡಿಂಗ್ ಹೆಡರ್ ಮೂಲದ ಬಗ್ಗೆ ಒಂದು ಪ್ರತಿಪಾದನೆ, ಅದರ ಸಾಕ್ಷ್ಯವಲ್ಲ.

ನಂತರ ಪೋರ್ಟಲ್ ಮತ್ತು ಸೇವೆ ಒಂದೇ ಮೂಲವನ್ನು ನೋಡುತ್ತವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ವಿಭಜಿತ ಟನೆಲಿಂಗ್, ಒಂದು ಪ್ರಾಕ್ಸಿ ಹಾಪ್ ಮತ್ತು IPv4 ಹಾಗೂ IPv6 ಎರಡು ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ ಎರಡು ಬೇರೆ ವಿಳಾಸಗಳನ್ನು ನೀಡಬಹುದು, ಆದ್ದರಿಂದ ಒಂದು ಮಾರ್ಗದಿಂದ ಸಕ್ರಿಯಗೊಳಿಸಿದ ಅನುದಾನ ಮುಂದಿನ ವಿನಂತಿಯನ್ನು ಆವರಿಸದೇ ಇರಬಹುದು.

ಸ್ಥಾಪಿಸುವ ಮೊದಲು ಅನುದಾನವನ್ನು ತೋರಿಸಿ

ಕೊಂಡಿ ತೆರೆಯುವುದು ಪ್ರಸ್ತಾವಿತ ಸೇವೆ, ಗಮನಿಸಿದ ಮೂಲ ಮತ್ತು ಅವಧಿಯನ್ನು ತೋರಿಸಬೇಕು ಮತ್ತು ಇನ್ನೂ ಏನನ್ನೂ ಬದಲಿಸಬಾರದು. ಆ ಒಂದೇ ಹೆಜ್ಜೆ ಇಮೇಲ್‌ನಿಂದ ಬಂದ ಕೊಂಡಿಯನ್ನು ಕ್ರಿಯೆಯಿಂದ ಪ್ರಸ್ತಾವನೆಯಾಗಿ ಬದಲಿಸುತ್ತದೆ ಮತ್ತು ಮುನ್ನೋಟ ಬಾಟ್ ಅಥವಾ ಮೇಲ್ ಸ್ಕ್ಯಾನರ್ ಅದನ್ನು ಸುಮ್ಮನೆ ಪಡೆದುಕೊಳ್ಳುವ ಮೂಲಕ ಪ್ರವೇಶ ನೀಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ.

ದೃಢೀಕರಣವು ಸಾಮಾನ್ಯ ಕ್ರಾಸ್-ಸೈಟ್ ಮತ್ತು ಮೂಲ ರಕ್ಷಣೆಗಳೊಂದಿಗೆ ಸ್ಥಿತಿ ಬದಲಿಸುವ ವಿನಂತಿಯಾಗಿರಬೇಕು. ಟೋಕನ್ ಏಕ-ಬಳಕೆಯಾಗಿರಬೇಕು ಮತ್ತು ನಿಯಮ ಸ್ಥಾಪನೆಯಾಗುವ ಕ್ಷಣದಲ್ಲೇ ಪರಮಾಣು ರೀತಿಯಲ್ಲಿ ವ್ಯಯವಾಗಬೇಕು, ಮತ್ತು ದಾಖಲೆಯು ಮಾಲೀಕ, ಸೇವೆ, ವಿಳಾಸ, ಅನುದಾನ ಗುರುತಿಸುವಿಕೆ ಮತ್ತು ಅವಧಿ ಮುಗಿಯುವಿಕೆಯನ್ನು ಎಂದಿಗೂ ಕಚ್ಚಾ ಟೋಕನ್ ಲಾಗ್ ಮಾಡದೆ ದಾಖಲಿಸಬೇಕು.

ಟೋಕನ್ ವಿತರಣೆಗೆ ನಿಯಮಕ್ಕೆ ಬೇಕಾದಷ್ಟೇ ಕಾಳಜಿ ಬೇಕು. ಅವಧಿ ಮುಗಿದ ಅಥವಾ ಈಗಾಗಲೇ ವ್ಯಯವಾದ ಕೊಂಡಿ ಇನ್ನೂ ನಿಯಮವನ್ನು ಸೃಷ್ಟಿಸಿದರೆ, ಅದು ಅದೇ ಕೀಲಿಯಿಂದ ಅಳವಡಿಸಿದ ಎರಡನೇ ಬಾಗಿಲು.

ಅನುದಾನ ಜೀವಂತವಾಗಿರುವಾಗಲೂ ವಿಳಾಸ ಹಂಚಿಕೆಯಾಗಿದೆ

ಕಚೇರಿ NAT, ವಾಹಕ NAT ಮತ್ತು ಹಂಚಿದ VPN ನಿರ್ಗಮನ ಪ್ರತಿಯೊಂದೂ ಹಲವು ಜನರನ್ನು ಒಂದು ವಿಳಾಸದ ಹಿಂದೆ ಇಡುತ್ತದೆ. ಆ ವಿಳಾಸವನ್ನು ಒಪ್ಪುವುದು ಅದರ ಹಿಂದಿರುವ ಎಲ್ಲರನ್ನೂ ಒಪ್ಪುವುದು — ಸೇವೆಯ ಮುಂದಿನ ಗಡಿಯವರೆಗೆ —, ಆದರೆ ಸೇವೆ ನಿರೀಕ್ಷಿಸುವ ಖಾತೆ ಯಾರ ಬಳಿ ಇದೆ ಎಂಬುದನ್ನು ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ನಿಯಮವನ್ನು ತೆಗೆಯುವುದೂ ಸಾರ್ವತ್ರಿಕ ಸಂಪರ್ಕ ಕಡಿತವಲ್ಲ. ಸ್ಥಾಪಿತ ಸಂಪರ್ಕಗಳು, ಸಂಗ್ರಹಿತ ಅಪ್ಲಿಕೇಶನ್ ಟೋಕನ್‌ಗಳು ಮತ್ತು ದೀರ್ಘಕಾಲಿಕ ಸೆಷನ್‌ಗಳು ನಿಯಮವನ್ನು ನಿಮಿಷಗಳು ಅಥವಾ ಅದಕ್ಕಿಂತ ಬಹಳ ಹೆಚ್ಚು ಕಾಲ ಮೀರಿ ಉಳಿಯಬಹುದು, ಆದ್ದರಿಂದ ನೀವು ಆಯ್ಕೆ ಮಾಡುವ ಆಯುಷ್ಯವು ನಿಯಮ ಎಷ್ಟು ಕಾಲ ಇರುತ್ತದೆ ಎಂಬುದನ್ನಲ್ಲ, ಒಪ್ಪಿಗೆಯ ನಂತರ ಸೇವೆ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಪ್ರತಿಬಿಂಬಿಸಬೇಕು.

ನಾಲ್ಕು ಸಂದರ್ಭಗಳು ಮತ್ತು ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ

ಅನುದಾನವು ಅದು ತಾಳಿಕೊಳ್ಳುವ ನಾಲ್ಕು ಸಂದರ್ಭಗಳಷ್ಟೇ ಒಳ್ಳೆಯದು: ಹೊಸ ಅನುಮತಿಸಿದ ವಿನಂತಿ, ಅನುಮೋದಿಸದ ವಿನಂತಿದಾರ, ಅದೇ ಕೊಂಡಿಯ ಪುನರಾವರ್ತನೆ ಮತ್ತು ಅವಧಿ ಮುಗಿದ ನಂತರದ ಅದೇ ವಿನಂತಿ.

ನಂತರ ಪ್ರತಿ ಕುಟುಂಬವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಸೇವೆ ಗಮನಿಸುವ ಮೂಲ ವಿಳಾಸ ಅವುಗಳ ನಡುವೆ ಭಿನ್ನವಾಗಿರಬಹುದು.

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

ಉಪಯುಕ್ತ ಫಲಿತಾಂಶ ಸಾಮಾನ್ಯ ಬಳಕೆದಾರ ಅಧಿಕಾರದ ಅಡಿಯಲ್ಲಿರುವ ತಾತ್ಕಾಲಿಕ, ಲೆಕ್ಕಪರಿಶೋಧನೀಯ ಒಪ್ಪಿಗೆ ನಿರ್ಧಾರ, ಮೊದಲು ಕ್ಲಿಕ್ ಮಾಡಿದವರ ಹೆಸರು ಹೊತ್ತ ಶಾಶ್ವತ ತೆರವಲ್ಲ.