VPN ಹಿಂದೆ ಇರುವ SaaS ನಿರ್ವಹಣಾ ಪ್ರದೇಶ: ಯಾವ ವಿಳಾಸವನ್ನು ನಂಬಬೇಕು?

ಸಾರ್ವಜನಿಕ SaaS ಪುಟಗಳು ಎಲ್ಲರಿಗೂ ತೆರೆದಿರಬಹುದು, ಆದರೆ ಅವುಗಳ ಹಿಂದಿನ ನಿರ್ವಹಣಾ ಕಾರ್ಯಾಚರಣೆಗಳು VPN ನ ಹೊರಗಿನ ಎಲ್ಲರನ್ನೂ ನಿರಾಕರಿಸುತ್ತವೆ. ಇದನ್ನು ಸಾಧ್ಯವಾಗಿಸುವ ಕಾರ್ಯವಿಧಾನವು ಗುಪ್ತ ಮೆನು ಅಥವಾ ಪ್ರತ್ಯೇಕ ಲಾಗಿನ್ ಪುಟವಲ್ಲ; ಅದು ವಿನಂತಿಯನ್ನು ತಲುಪಿಸಿದ ನೆಟ್ವರ್ಕ್ ಮಾರ್ಗದ ಪರಿಶೀಲನೆ. ವಿಳಾಸದ ಸಾಕ್ಷ್ಯ ತಪ್ಪಾದರೆ ಪರಿಶೀಲನೆ ನಿಜವಾದ ನಿರ್ವಾಹಕರನ್ನು ಹೊರಗಿಡುತ್ತದೆ ಅಥವಾ ಹೆಡರ್ ಟೈಪ್ ಮಾಡಬಲ್ಲ ಯಾರನ್ನಾದರೂ ಒಳಗೆ ಬಿಡುತ್ತದೆ. ಮೂಲವು ನಿಜವಾಗಿ ಏನನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂಬುದರಿಂದ ಆರಂಭಿಸಿ.

ಸುರಂಗದ ನಂತರ ಮೂಲವು ನಿಜವಾಗಿ ಏನನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ

ಬ್ರೌಸರ್ ಇಂಟರ್ನೆಟ್ ಸಂಚಾರವನ್ನೂ ಸಾಗಿಸುವ VPN ಮೂಲಕ ಸಾರ್ವಜನಿಕ ಸೈಟ್ ತಲುಪಿದಾಗ, ಗೇಟ್ವೇ ಹೊರಡುವ ಮೊದಲು ಸಂಪರ್ಕವನ್ನು ಅನುವಾದಿಸುತ್ತದೆ. SaaS ಗೇಟ್ವೇಯ ಸಾರ್ವಜನಿಕ ಹೊರಹೋಗುವ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ವಿಳಾಸ ಅಥವಾ ಸಣ್ಣ ಶ್ರೇಣಿ, ಮತ್ತು ಲ್ಯಾಪ್ಟಾಪ್ನ ಸುರಂಗ ವಿಳಾಸವನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ 10.90.0.42 ಅನ್ನು ಅನುಮತಿಸಲಾದ ಪಟ್ಟಿಗೆ ಸೇರಿಸುವುದು ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಆದ್ದರಿಂದ ಇಡೀ RFC 1918 ಸೇರಿಸುವುದು ಇನ್ನೂ ಜೋರಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ: ಎರಡನೆಯದು ನಿಮ್ಮನ್ನು ತಲುಪಬಲ್ಲ ಪ್ರತಿ ಖಾಸಗಿ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಒಳಗೆ ಬಿಡುತ್ತದೆ. ಷರತ್ತು ಹಾಕಲು ಯೋಗ್ಯವಾದ ಏಕೈಕ ವಿಳಾಸವೆಂದರೆ ನಿಮ್ಮ ಸಂಸ್ಥೆ ನಿರ್ಗಮನದಲ್ಲಿ ನಿಜವಾಗಿ ಹೊಂದಿರುವ ವಿಳಾಸ.

curl -s https://ifconfig.me
dig +short admin.example.com

ವಿಭಜಿತ ಸುರಂಗೀಕರಣವು ಈ ಊಹೆಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ಮುರಿಯುತ್ತದೆ. VPN ಖಾಸಗಿ ಕಚೇರಿ ಮಾರ್ಗಗಳನ್ನು ಮಾತ್ರ ಸಾಗಿಸಿದರೆ, ಸಾರ್ವಜನಿಕ ನಿರ್ವಹಣಾ ಹೋಸ್ಟ್ಹೆಸರಿಗೆ ವಿನಂತಿ ಸ್ಥಳೀಯ ISP ಮೂಲಕ ಹೊರಡುತ್ತದೆ ಮತ್ತು ಮೂಲವು ವಸತಿ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ. ಸಂಪರ್ಕಿತ VPN ಐಕಾನ್ ಈ ನಿರ್ದಿಷ್ಟ ಗಮ್ಯಸ್ಥಾನದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸುರಂಗವನ್ನಲ್ಲ, ಗಮ್ಯಸ್ಥಾನವನ್ನು ಪರೀಕ್ಷಿಸಿ.

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

ವಿಳಾಸವನ್ನು ಮರುಬರೆಯುವ ಪ್ರಾಕ್ಸಿಯನ್ನು ಮಾತ್ರ ನಂಬಿ

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

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

ಅದೇ ತರ್ಕ PROXY ಪ್ರೋಟೋಕಾಲ್ಗೂ ಅನ್ವಯಿಸುತ್ತದೆ: ಶ್ರೋತೃವು ಪ್ರಾಕ್ಸಿ ತಲುಪಬಲ್ಲ ಮತ್ತು ಬೇರೆ ಯಾವುದೂ ತಲುಪಲಾಗದ ಇಂಟರ್ಫೇಸ್ಗೆ ಬದ್ಧವಾಗಿದ್ದಾಗ ಮಾತ್ರ ಅದು ವಿಶ್ವಾಸಾರ್ಹ. ಕಾಣೆಯಾದ ವಿಳಾಸ ಸಂದರ್ಭವು ಸಂರಕ್ಷಿತ ಪರಿಶೀಲನೆಯನ್ನು ವಿಫಲಗೊಳಿಸಬೇಕು, ಡೀಫಾಲ್ಟ್ ಅನುಮತಿಗೆ ಬೀಳಬಾರದು. ಇಲ್ಲದ ಹೆಡರ್ ವಿಶ್ವಾಸಾರ್ಹ ಮಾರ್ಗದ ಸಾಕ್ಷ್ಯವಲ್ಲ.

ಷರತ್ತನ್ನು ಪ್ರತಿ ಸಂರಕ್ಷಿತ ಕಾರ್ಯಾಚರಣೆಗೆ ಲಗತ್ತಿಸಿ

ಪರಿಶೀಲನೆಯನ್ನು ಪ್ರತಿ ಸಂರಕ್ಷಿತ ಕಾರ್ಯಾಚರಣೆ ಹಾದುಹೋಗುವ ಅಧಿಕಾರ ಮಿತಿಗೆ ಇರಿಸಿ, ಮೆನು ರೆಂಡರ್ ಮಾಡುವ ಪುಟದಲ್ಲಲ್ಲ. ರೂಟ್ ಗುಂಪುಗಳು, ಮಿಡಲ್ವೇರ್ ಅಥವಾ ನೀತಿ ಪದರ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತವೆ; ಪ್ರತಿ ಹ್ಯಾಂಡ್ಲರ್ಗೆ ಪ್ರತಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಮುಂದಿನ ತ್ರೈಮಾಸಿಕದಲ್ಲಿ ಯಾರಾದರೂ ಸೇರಿಸುವ ಹ್ಯಾಂಡ್ಲರ್ಗೆ ಅದು ಇರುವುದಿಲ್ಲ.

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

ಅದೇ ಮಿತಿಯು JSON API, ರಫ್ತುಗಳು, ಸಹಿ ಮಾಡಿದ ಡೌನ್ಲೋಡ್ URL ಗಳು ಮತ್ತು WebSocket ಕೈಹಿಡಿತವನ್ನು ಸಹ ಒಳಗೊಳ್ಳಬೇಕು, ಏಕೆಂದರೆ ಅವುಗಳಲ್ಲಿ ಯಾವುದಕ್ಕೂ ಮೊದಲು HTML ಪುಟವನ್ನು ವಿನಂತಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. VPN ಸಕ್ರಿಯವಾಗಿದ್ದಾಗ ರಚಿಸಿದ ಡೌನ್ಲೋಡ್ ಲಿಂಕ್, ಡೌನ್ಲೋಡ್ ಎಂಡ್ಪಾಯಿಂಟ್ ಮತ್ತೆ ಪರಿಶೀಲಿಸದಿದ್ದರೆ ನಂತರವೂ ಮಾನ್ಯವಾಗಿರುತ್ತದೆ. ದೀರ್ಘಕಾಲಿಕ ಸೆಷನ್ಗಳಿಗೂ ಮರುಮೌಲ್ಯಮಾಪನ ನಿಯಮ ಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಒಂದು ದೃಢೀಕೃತ ವಿನಂತಿ ಶಾಶ್ವತ ವಿನಾಯಿತಿಯಾಗುತ್ತದೆ. ಡೀಫಾಲ್ಟ್ ನಿರಾಕರಣೆಯೇ ಸಿಬ್ಬಂದಿ ಬದಲಾವಣೆಯನ್ನು ಮೀರಿ ಉಳಿಯುವ ಏಕೈಕ ಸೆಟ್ಟಿಂಗ್.

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

ನೀವು ಈಗಷ್ಟೇ ಮುಚ್ಚಿದ ಬೈಪಾಸ್ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ

ಸಂತೋಷದ ಮಾರ್ಗವನ್ನಲ್ಲ, ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಅನ್ನು ಅಭ್ಯಾಸ ಮಾಡಿ: VPN ಮೂಲಕ ನಿರ್ವಾಹಕ, ಅದಿಲ್ಲದೆ ಅದೇ ನಿರ್ವಾಹಕ, ಅದರ ಮೂಲಕ ನಿರ್ವಾಹಕರಲ್ಲದವರು, ಮತ್ತು ನಕಲಿ ವಿಳಾಸ ಹೆಡರ್. ನೇರವಾಗಿ ಮೂಲಕ್ಕೆ ವಿನಂತಿ ಮತ್ತು ಕ್ಯಾಶ್ ಮಾಡಿದ ಪ್ರತಿಕ್ರಿಯೆಯ ವಿನಂತಿ ಸೇರಿಸಿ, ಏಕೆಂದರೆ ಆ ಎರಡೇ ಮುಂಭಾಗವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಿಟ್ಟುಬಿಡುತ್ತವೆ.

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

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

ಹೊರಹೋಗುವ ವಿಳಾಸವು ಅನುಮತಿಸಲಾದ ನೆಟ್ವರ್ಕ್ ಮಾರ್ಗವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ವ್ಯಕ್ತಿಯನ್ನಲ್ಲ ಮತ್ತು ನಿರ್ವಹಿತ ಸಾಧನವನ್ನಲ್ಲ. ಅದನ್ನು ದೃಢೀಕರಣ ಮತ್ತು ಅನುಮತಿಯ ಪಕ್ಕದಲ್ಲಿ ಒಂದು ಷರತ್ತಾಗಿ ಇರಿಸಿ, ಮತ್ತು ಇಡೀ ಉತ್ಪನ್ನವನ್ನು VPN-ಮಾತ್ರ ಸೇವೆಯಾಗಿ ಮಾಡದೆ ನಿರ್ವಹಣಾ ಪ್ರದೇಶವು ಕಿರಿದಾಗಿರುತ್ತದೆ. ಆ ಬೇರ್ಪಡಿಕೆಯೇ ವಿನ್ಯಾಸ, ಅದರ ಮಿತಿಯಲ್ಲ.