VPN ನಿಯಮವು ಒಂದು ಫೈಲ್ ಅಪ್ಲೋಡ್ ಆಗುವುದನ್ನು ಏಕೆ ತಡೆಯಲಾರದು
ಸೇವೆಯನ್ನು ತಲುಪುವುದು ಮತ್ತು ಅದರಿಂದ ಯಾವ ಫೈಲ್‌ಗಳು ಹೊರಡುತ್ತವೆ ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸುವುದು ಎರಡು ಅಗತ್ಯಗಳು. ನಿಯಮವನ್ನು ಫೈಲ್ ಕಾಣುವ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಿ: ಮೇಲ್, ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ ಎಂಡ್ಪಾಯಿಂಟ್ ಏಜೆಂಟ್.
ಒಂದು ಸಣ್ಣ ತಂಡ ತನ್ನ ಕೆಲಸದ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ದೂರಸ್ಥ ಪ್ರವೇಶವನ್ನು ಕೇಳುತ್ತದೆ ಮತ್ತು ಅದೇ ಉಸಿರಿನಲ್ಲಿ ಕೆಲವು ಲಗತ್ತುಗಳು ಕಂಪನಿಯನ್ನು ಬಿಡುವುದನ್ನು ನಿಲ್ಲಿಸಬೇಕೆಂದು ಕೇಳುತ್ತದೆ. ಎರಡೂ ವಿನಂತಿಗಳು ಒಂದೇ VPN ಬದಲಾವಣೆಯಂತೆ ಕೇಳಿಸುತ್ತವೆ. ಅವು ಬೇರೆ ಬೇರೆ ಜಾರಿ ಬಿಂದುಗಳನ್ನು ಹೊಂದಿರುವ ಎರಡು ಅಗತ್ಯಗಳು, ಮತ್ತು ಮೊದಲನೆಯದನ್ನು ಪೂರೈಸುವ ನಿಯಮ ಎರಡನೆಯದಕ್ಕೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ. ಮೊದಲು ಕ್ರಿಯೆ ಮತ್ತು ಡೇಟಾವನ್ನು ಹೆಸರಿಸಿ, ನಂತರ ಅವುಗಳನ್ನು ನಿಜವಾಗಿ ನೋಡಬಲ್ಲ ಘಟಕವನ್ನು ಆರಿಸಿ.
ಒಂದು ವಿನಂತಿ, ಎರಡು ಅಗತ್ಯಗಳು
ಮೊದಲ ಅಗತ್ಯವು ತಲುಪುವಿಕೆಯ ಬಗ್ಗೆ: ಯಾವ ಬಳಕೆದಾರರು ಮತ್ತು ಸಾಧನಗಳು ಯಾವ ಸೇವೆಗೆ ಸಂಪರ್ಕ ತೆರೆಯಬಹುದು. ಎರಡನೆಯದು ಆ ಸಂಪರ್ಕ ಇದ್ದ ನಂತರದ ನಡವಳಿಕೆಯ ಬಗ್ಗೆ: ಯಾವ ದಾಖಲೆಗಳನ್ನು ಲಗತ್ತಿಸಬಹುದು, ಅಂಟಿಸಬಹುದು ಅಥವಾ ಅಪ್ಲೋಡ್ ಮಾಡಬಹುದು. ಸುರಂಗವು ಮೊದಲನೆಯದರ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ವಿನ್ಯಾಸದಿಂದ ಎರಡನೆಯದಕ್ಕೆ ಕುರುಡು.
IP ಮಟ್ಟದ ನಿಯಂತ್ರಣವು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮುಂದೆ ಕಳುಹಿಸುತ್ತದೆ. ಅದು ಬಹು-ಭಾಗ ಅಪ್ಲೋಡ್ ಅನ್ನು ವಿಶ್ಲೇಷಿಸುವುದಿಲ್ಲ, PDF ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ ಮತ್ತು ಸ್ಪ್ರೆಡ್‌ಶೀಟ್‌ನಲ್ಲಿ ಖಾತೆ ಸಂಖ್ಯೆಗಳಿವೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ. ಅದರಿಂದ ಇದನ್ನು ನಿರೀಕ್ಷಿಸುವುದು ಸಂರಚನಾ ತಪ್ಪಲ್ಲ; ಅದು ವರ್ಗ ದೋಷ.
ಉತ್ಪನ್ನವನ್ನು ಹುಡುಕುವ ಮೊದಲು ಅಗತ್ಯವನ್ನು ಅದೇ ರೂಪದಲ್ಲಿ ಗಟ್ಟಿಯಾಗಿ ಹೇಳಿ. «ಬಳಕೆದಾರರು ಫೈಲ್ ಪೋರ್ಟಲ್ ತಲುಪಬಹುದು» ಮತ್ತು «ಬಳಕೆದಾರರು ಗ್ರಾಹಕ ಪಟ್ಟಿಗಳನ್ನು ಫೈಲ್ ಪೋರ್ಟಲ್‌ಗೆ ಅಪ್ಲೋಡ್ ಮಾಡಲಾಗದು» ಬೇರೆ ವಾಕ್ಯಗಳು, ಮತ್ತು ಎರಡನೆಯದು ಮಾತ್ರ ವಿಷಯ ನೀತಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಫೈಲ್ ನೋಡಬಲ್ಲ ಘಟಕವನ್ನು ಆರಿಸಿ
ಜಾರಿ ಫೈಲ್ ಓದಬಹುದಾದ ಸ್ಥಳದಲ್ಲಿ ನಡೆಯಬೇಕು. ಇಮೇಲ್‌ಗೆ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಮೇಲ್ ವೇದಿಕೆ ಅಥವಾ ಗೇಟ್‌ವೇ, ಅದು ಈಗಾಗಲೇ ಲಗತ್ತುಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ವಿತರಣೆಗೆ ಮೊದಲು ಅವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಹುದು. ಅನುಮೋದಿತ ಸೇವೆಗೆ ಬ್ರೌಸರ್ ಅಪ್ಲೋಡ್‌ಗಳಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಸ್ವತಃ ವಿಷಯವನ್ನು ನೋಡುವ ಏಕೈಕ ಪಕ್ಷವಾಗಿರಬಹುದು. ನಿರ್ವಹಿತ ಲ್ಯಾಪ್‌ಟಾಪ್ ಫೈಲ್‌ಗಳನ್ನು ತೆಗೆಯಬಹುದಾದ ಮಾಧ್ಯಮಕ್ಕೆ ನಕಲಿಸುವಾಗ ಎಂಡ್ಪಾಯಿಂಟ್ ಏಜೆಂಟ್ ಆ ಕ್ರಿಯೆಯನ್ನು ನೋಡುತ್ತದೆ.
| Where the file moves | Component that can see it |
|---|---|
| Email attachment | Mail gateway or mail platform policy |
| Upload to a web application | The application, or an inspection proxy that terminates TLS |
| Copy to USB or local folder | Endpoint agent on the device |
| Anything inside the tunnel | Nothing, unless one of the above is present |
ಕೆಲವು ವಾಣಿಜ್ಯ ದೂರಸ್ಥ-ಪ್ರವೇಶ ಸೂಟ್‌ಗಳು ಎಂಡ್ಪಾಯಿಂಟ್ ಏಜೆಂಟ್, ವೆಬ್ ನಿಯಂತ್ರಣ ಮತ್ತು ಡೇಟಾ-ನಷ್ಟ ತಡೆಗಟ್ಟುವಿಕೆ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಒಟ್ಟಿಗೆ ನೀಡುತ್ತವೆ. ಆ ಘಟಕಗಳು ವಿಷಯ ನೀತಿಯನ್ನು ಜಾರಿಗೊಳಿಸಬಹುದು, ಆದರೆ ಸಾಮರ್ಥ್ಯ ಸುರಂಗಕ್ಕಲ್ಲ, ಮಾಡ್ಯೂಲ್‌ಗೆ ಸೇರಿದ್ದು. ಫಲಿತಾಂಶವನ್ನು ಭರವಸೆ ನೀಡುವ ಮೊದಲು ಸೂಟ್ ನಿಜವಾಗಿ ಏನನ್ನು ಒಳಗೊಂಡಿದೆ ಎಂದು ಓದಿ.
Microsoft ನ Purview ಡೇಟಾ-ನಷ್ಟ ತಡೆಗಟ್ಟುವಿಕೆ ಅವಲೋಕನ ಹೋಲಿಕೆಗೆ ಉಪಯುಕ್ತ ಮಾದರಿ: ಅದು ನೀತಿಗಳನ್ನು ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿ ಪ್ರಕಾರಗಳು, ಸ್ಥಳಗಳು ಮತ್ತು ಚಟುವಟಿಕೆಗಳ ಮೂಲಕ ವಿವರಿಸುತ್ತದೆ. ಆ ಪದಕೋಶವು ವಿಷಯ ಮತ್ತು ಕ್ರಿಯೆಗಳ ಬಗ್ಗೆ, IP ಪೂರ್ವಪ್ರತ್ಯಯಗಳ ಬಗ್ಗೆ ಅಲ್ಲ.
TLS ಸುರಂಗದಿಂದ ಪಾರಾಗಿ ಉಳಿಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಯೋಜಿಸಿ
ಅಪ್ಲಿಕೇಶನ್ ಗೂಢಲಿಪೀಕರಣವು ಕ್ಲೈಂಟ್ ಮತ್ತು ಸೇವೆಯ ನಡುವೆ ಮಾತುಕತೆಯಿಂದ ನಿರ್ಧಾರವಾಗುತ್ತದೆ, ಮತ್ತು VPN ಸುರಂಗವು ಆ ಬೈಟ್‌ಗಳನ್ನು ತೆರೆಯದೆ ಸಾಗಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಮಾರ್ಗದಲ್ಲಿನ ಗೇಟ್‌ವೇ ಲಗತ್ತನ್ನು ವರ್ಗೀಕರಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ತಾನಾಗಿಯೇ ಪಡೆಯುವುದಿಲ್ಲ, ಮಾರ್ಗದ ಎಷ್ಟು ಭಾಗ ಅದರದ್ದೇ ಆಗಿದ್ದರೂ.
ಸಾಗಣೆಯಲ್ಲಿ ವಿಷಯವನ್ನು ಪರಿಶೀಲಿಸಲು ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರಮಾಣಪತ್ರದೊಂದಿಗೆ TLS ಅನ್ನು ಕೊನೆಗೊಳಿಸುವ ಘಟಕ ಬೇಕು, ಮತ್ತು ಇದು ತನ್ನದೇ ಆದ ಗೋಪ್ಯತೆ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಪರಿಣಾಮಗಳನ್ನು ಹೊಂದಿರುವ ದೊಡ್ಡ ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ. ಇದು VPN ಪ್ರೊಫೈಲ್‌ನ ಚೆಕ್‌ಬಾಕ್ಸ್ ಅಲ್ಲ. ಕ್ಲೈಂಟ್‌ಗಳು ಪರಿಶೀಲನಾ ಪ್ರಮಾಣಪತ್ರವನ್ನು ನಂಬಬೇಕು, ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಪಿನ್ ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಒಡೆಯುತ್ತವೆ, ಮತ್ತು ನಿರ್ವಾಹಕರು ಮೊದಲು ಓದಲಾಗದ ಟ್ರಾಫಿಕ್ ಓದುವ ಸಾಮರ್ಥ್ಯ ಪಡೆಯುತ್ತಾರೆ. ಈ ನಿರ್ಧಾರ ಸುರಂಗ ನಡೆಸುವವರದ್ದಲ್ಲ, ಭದ್ರತಾ ಮಾಲೀಕರದ್ದು ಎಂಬುದಕ್ಕೆ ಇವೇ ಕಾರಣಗಳು.
ಆದ್ದರಿಂದ «VPN ಈ ಅಪ್ಲೋಡ್ ಅನ್ನು ತಡೆಯಬಹುದೇ» ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಪ್ರಾಮಾಣಿಕ ಉತ್ತರ ಸಾಮಾನ್ಯವಾಗಿ ಇಲ್ಲ, ಮತ್ತು ಅದರ ನಂತರ ಒಂದು ನಿರ್ದಿಷ್ಟ ಪರ್ಯಾಯ ಬರುತ್ತದೆ. ಪರ್ಯಾಯವು ಅಪ್ಲಿಕೇಶನ್-ಮಟ್ಟದ ನಿರ್ಬಂಧಗಳು, ಮೇಲ್ ನಿಯಮ ಅಥವಾ ಎಂಡ್ಪಾಯಿಂಟ್ ನೀತಿಯಾಗಿರಬಹುದು, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಅದನ್ನು ಬದಲಾಯಿಸಬಲ್ಲ ಮಾಲೀಕರಿದ್ದಾರೆ.
ನಿಯಮಕ್ಕೆ ಮೊದಲು ಸ್ವೀಕೃತಿ ಪರೀಕ್ಷೆ ಬರೆಯಿರಿ
ವಿಷಯ ನಿಯಮಕ್ಕೆ ಒಂದಲ್ಲ, ಎರಡು ಉದಾಹರಣೆಗಳು ಬೇಕು: ಕೆಲಸ ಮುಂದುವರಿಯಬೇಕಾದ ಅನುಮತಿಸಿದ ಕ್ರಿಯೆ ಮತ್ತು ನಿಲ್ಲಿಸಬೇಕಾದ ನಿಷಿದ್ಧ ಕ್ರಿಯೆ. ವ್ಯಾಪ್ತಿಯಲ್ಲಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ಸಾಧನಗಳಿಂದ ಎರಡನ್ನೂ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಒಂದೇ ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ನೀತಿ ಯಾರೋ ಕೇಳಿದ ನೀತಿಯಲ್ಲ.
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/uploadಮೊದಲ ವಿನಂತಿಯನ್ನು ನಿಯಮವನ್ನು ಹೊಂದಿರುವ ಘಟಕ ನಿರಾಕರಿಸಬೇಕು, ಮತ್ತು ಎರಡನೆಯದು ಯಶಸ್ವಿಯಾಗಬೇಕು. ಎರಡೂ ಯಶಸ್ವಿಯಾದರೆ ನಿಯಂತ್ರಣ ಮಾರ್ಗದಲ್ಲಿಲ್ಲ. ಎರಡೂ ವಿಫಲವಾದರೆ ನೀವು ಸೇವೆಯನ್ನು ರಕ್ಷಿಸುವ ಬದಲು ಒಡೆದಿದ್ದೀರಿ, ಇದು ಅನುಮತಿಸಿದ ಉದಾಹರಣೆ ಇಲ್ಲದೆ ಬರೆದ ನಿಯಮದ ಸಾಮಾನ್ಯ ಫಲಿತಾಂಶ.
ಬಳಕೆದಾರರು ಏನನ್ನು ನೋಡುತ್ತಾರೆ, ಯಾರು ವಿನಾಯಿತಿ ನೀಡಬಹುದು ಮತ್ತು ನಿರ್ವಾಹಕರು ನಂತರ ಎಲ್ಲಿ ನಿರ್ಧಾರವನ್ನು ದೃಢೀಕರಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಮೊದಲೇ ನಿರ್ಧರಿಸಿ. ಸಂದೇಶವಿಲ್ಲದೆ ತಡೆಹಿಡಿಯಲಾದ ಅಪ್ಲೋಡ್ ಬೆಂಬಲ ಟಿಕೆಟ್ ಉಂಟುಮಾಡುತ್ತದೆ, ಮತ್ತು ಯಾರೂ ಆಡಿಟ್ ಮಾಡಲಾಗದ ನಿಯಮ ಚರ್ಚೆ ಉಂಟುಮಾಡುತ್ತದೆ. ನೀತಿ ಜಾರಿಗೆ ಬರುವ ಮೊದಲು ಬರೆದ ಒಂದು ವಾಕ್ಯದ ದಾಖಲೀಕರಣದಿಂದ ಎರಡನ್ನೂ ತಪ್ಪಿಸಬಹುದು.
ಕೊನೆಯದಾಗಿ, ಎರಡು ಅಗತ್ಯಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಮಾಲೀಕರೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ಟಿಕೆಟ್‌ಗಳಲ್ಲಿ ಇರಿಸಿ. ಅವನ್ನು «VPN» ಅಡಿಯಲ್ಲಿ ಒಟ್ಟುಗೂಡಿಸುವುದು ನೆಟ್‌ವರ್ಕ್ ತಂಡಕ್ಕೆ ವಿಷಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಕೇಳಲಾಗುತ್ತದೆ ಮತ್ತು ಸುರಂಗ ಏರಿದಾಗ ವಿಷಯ ಸಮಸ್ಯೆ ಪರಿಹರಿಸಲ್ಪಟ್ಟಿದೆ ಎಂದು ಘೋಷಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ.