ನಿಯೋಜಿತ ಪ್ರವೇಶ
ಡೆವಲಪರ್ ಒಬ್ಬರನ್ನು ಸೇರಿಸಿಕೊಳ್ಳಿ, ಬಿಲ್ಲಿಂಗ್ ಅನ್ನು ನಿಮ್ಮ ಲೆಕ್ಕಪರಿಶೋಧಕರಿಗೆ ಒಪ್ಪಿಸಿ, ಕ್ಲೈಂಟ್‌ಗೆ ಅವರ ಸ್ವಂತ ಸೈಟ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸಲು ಕೇವಲ-ಓದುವ ಪ್ರವೇಶವನ್ನು ನೀಡಿ, ಅಥವಾ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಶೀಲಿಸಲು ನಮ್ಮ ಬೆಂಬಲ ತಂಡಕ್ಕೆ ಅನುಮತಿಸಿ. ಪ್ರತಿಯೊಂದು ಅನುದಾನವೂ ನಿರ್ದಿಷ್ಟ ಅನುಮತಿಗಳನ್ನು ಹೊಂದಿರುವ ಪಾತ್ರವಾಗಿದ್ದು, ಒಂದು ಸಂಸ್ಥೆಗೆ ಸೀಮಿತವಾಗಿರುತ್ತದೆ, ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಜಾರಿಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಕೇವಲ-ಸೇರ್ಪಡೆ ಮಾಡಬಹುದಾದ ಆಡಿಟ್ ಲಾಗ್ನಲ್ಲಿ ದಾಖಲಿಸಲಾಗುತ್ತದೆ.
ಒಂದೇ ಲಾಗಿನ್ ವಿವರಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದರಿಂದ ಖಾತೆಯ ಪ್ರವೇಶದಲ್ಲಿ ಸಮಸ್ಯೆಗಳು ಉಂಟಾಗುತ್ತವೆ. Zinn Digital® ನಲ್ಲಿ ಪ್ರತಿಯೊಬ್ಬ ವ್ಯಕ್ತಿಯೂ ತನ್ನದೇ ಆದ ಪ್ರತ್ಯೇಕ ಗುರುತನ್ನು ಹೊಂದಿರುತ್ತಾರೆ, ಮತ್ತು ಪ್ರವೇಶವು ಒಂದು ಸದಸ್ಯತ್ವವಾಗಿದೆ — ಒಬ್ಬ ಬಳಕೆದಾರ, ಒಂದು ಸಂಸ್ಥೆ ಮತ್ತು ಒಂದು ಪಾತ್ರ — ಇದನ್ನು ನೀವು ಸ್ವತಂತ್ರವಾಗಿ ನೀಡಬಹುದು, ಬದಲಾಯಿಸಬಹುದು ಅಥವಾ ರದ್ದುಗೊಳಿಸಬಹುದು.
ಪ್ರತಿಯೊಬ್ಬ ಸಹಯೋಗಿಯೂ ನಮ್ಮ ಗುರುತಿನ ಪದರವಾದ Keycloak ಮೂಲಕ ತಮ್ಮದೇ ಆದ ಗುರುತಿನೊಂದಿಗೆ ಸೈನ್ ಇನ್ ಮಾಡುತ್ತಾರೆ. ಯಾರೂ ನಿಮ್ಮ ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಟೈಪ್ ಮಾಡುವುದಿಲ್ಲ, ಯಾರೂ ಬ್ರೌಸರ್ ಸೆಶನ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು ಯಾರನ್ನಾದರೂ ತೆಗೆದುಹಾಕುವುದು ಪಾಸ್‌ವರ್ಡ್ ಬದಲಾಯಿಸುವುದು ಹಾಗೂ ಅದನ್ನು ಬೇರೆ ಯಾರು ತಿಳಿದಿದ್ದಾರೆಂದು ಕಂಡುಹಿಡಿಯಲು ಹೆಣಗಾಡುವುದರ ಬದಲಾಗಿ ಕೇವಲ ಒಂದು ಕ್ರಿಯೆಯಾಗಿದೆ.
ಖಾತೆಗಳು ಶ್ರೇಣೀಕೃತವಾಗಿವೆ — ಮರುಮಾರಾಟಗಾರರ ಸಂಸ್ಥೆಯು ಗ್ರಾಹಕ ಸಂಸ್ಥೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಮತ್ತು ಗ್ರಾಹಕ ಸಂಸ್ಥೆಗಳು ಸೈಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. ಸದಸ್ಯತ್ವವು ಒಂದು ಸಂಸ್ಥೆ ಮತ್ತು ಅದರ ಅಡಿಯಲ್ಲಿರುವ ಎಲ್ಲದಕ್ಕೂ ಅನ್ವಯಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಇತರ ಗ್ರಾಹಕರನ್ನು ಬಹಿರಂಗಪಡಿಸದೆ ನೀವು ಏಜೆನ್ಸಿ ಗ್ರಾಹಕರಿಗೆ ಅವರ ಸ್ವಂತ ಸಂಸ್ಥೆಯ ನಿಯಂತ್ರಣವನ್ನು ನೀಡಬಹುದು.
ಬಾಡಿಗೆದಾರರ ಪ್ರತ್ಯೇಕತೆಯು ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ನಲ್ಲಿರುವ ಫಿಲ್ಟರ್ ಅಲ್ಲ, ಅದನ್ನು ದೋಷವು ತಪ್ಪಿಸಬಹುದು. Postgres ರೋ-ಲೆವೆಲ್ ಸೆಕ್ಯುರಿಟಿಯು ಪ್ರತಿಯೊಂದು ಕ್ವೆರಿಯನ್ನು ಕರೆದಾರರ ಸಂಸ್ಥೆಯ ಉಪವೃಕ್ಷಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ವ್ಯಾಪ್ತಿಯ ಹೊರಗಿನ ವಿನಂತಿಗೆ ಹಿಂತಿರುಗಿಸಲು ಏನೂ ಇರುವುದಿಲ್ಲ.
ನಿಮ್ಮ ವ್ಯಾಪ್ತಿಯ ಹೊರಗಿನ ಸಂಸ್ಥೆ ಅಥವಾ ಸೈಟ್‌ಗಾಗಿ ವಿನಂತಿಸಿದರೆ, API ಅನುಮತಿ ದೋಷದ ಬದಲಿಗೆ ಕೇವಲ 'ಕಂಡುಬಂದಿಲ್ಲ' (not-found) ಎಂದು ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ಅನುಮತಿ ದೋಷವು ದಾಖಲೆಯು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ; ಆದರೆ 'ಕಂಡುಬಂದಿಲ್ಲ' ಎಂಬುದು ಹೊರಗಿನವರಿಗೆ ಏನನ್ನೂ ತಿಳಿಸುವುದಿಲ್ಲ.
ಅನುಮತಿಗಳು ನಿರ್ದಿಷ್ಟ ಕೀಗಳಾಗಿವೆ — sites.restart ಅಥವಾ billing.refund ನಂತಹ ಮಾಡ್ಯೂಲ್ ಜೊತೆಗೆ ಕ್ರಿಯೆ — ಮತ್ತು ಪಾತ್ರಗಳು ಅವುಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತವೆ. ನಾಲ್ಕು ಪಾತ್ರಗಳು ನೈಜ ತಂಡಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ಮಾದರಿಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ನಾವು ಒದಗಿಸುವ ಡೇಟಾವಾಗಿದೆ, ಕೋಡ್‌ನಲ್ಲಿ ಅಡಗಿರುವ ತರ್ಕವಲ್ಲ.
ಪೂರ್ಣ ನಿಯಂತ್ರಣ: ಉಪ ಸಂಸ್ಥೆಗಳನ್ನು ರಚಿಸಿ, ಸದಸ್ಯರನ್ನು ಆಹ್ವಾನಿಸಿ ಮತ್ತು ತೆಗೆದುಹಾಕಿ, ಪಾತ್ರಗಳನ್ನು ಬದಲಾಯಿಸಿ, API ಕೀಗಳನ್ನು ನಿರ್ವಹಿಸಿ, ಸೈಟ್‌ಗಳನ್ನು ರಚಿಸಿ, ಮರುಪ್ರಾರಂಭಿಸಿ, ಪರ್ಜ್ ಮಾಡಿ, ಅಮಾನತುಗೊಳಿಸಿ ಮತ್ತು ಅಳಿಸಿ, ಬಿಲ್ಲಿಂಗ್ ಮತ್ತು ಇನ್‌ವಾಯ್ಸ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಿ, ಟಿಕೆಟ್‌ಗಳನ್ನು ಸಲ್ಲಿಸಿ ಮತ್ತು ಆಡಿಟ್ ಲಾಗ್ ಅನ್ನು ಓದಿ. ನಿಮಗಾಗಿ ನೀವು ಇರಿಸಿಕೊಳ್ಳುವ ಪಾತ್ರ.
ಸಂಸ್ಥೆ, ಅದರ ಸದಸ್ಯರು ಮತ್ತು ಯೋಜನಾ ಕ್ಯಾಟಲಾಗ್ ಅನ್ನು ವೀಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಇನ್‌ವಾಯ್ಸ್‌ಗಳು, ಪಾವತಿ ವಿಧಾನಗಳು ಮತ್ತು ಶುಲ್ಕಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಯಾವುದೇ ಸೈಟ್ ಅನ್ನು ರಚಿಸಲು, ಬದಲಾಯಿಸಲು ಅಥವಾ ಅಳಿಸಲು ಪ್ರವೇಶವಿಲ್ಲ — ಬಾಹ್ಯ ಲೆಕ್ಕಪರಿಶೋಧಕರು ಹೊಂದಿರಬೇಕಾದ ನಿಖರವಾದ ಸ್ವರೂಪ.
ಸೈಟ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ರಚಿಸುತ್ತದೆ, ಸೇವೆಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಕ್ಯಾಶ್ ತೆರವುಗೊಳಿಸುತ್ತದೆ, API ಕೀಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಟಿಕೆಟ್‌ಗಳನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ. ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಹೊರಗಿಡಲಾಗಿದೆ: ಬಿಲ್ಲಿಂಗ್, ಇನ್‌ವಾಯ್ಸ್‌ಗಳು, ಪಾವತಿ ವಿಧಾನಗಳು, ಸದಸ್ಯರ ನಿರ್ವಹಣೆ, ಸೈಟ್ ಅಮಾನತು ಮತ್ತು ಸೈಟ್ ಅಳಿಸುವಿಕೆ. ಗುತ್ತಿಗೆದಾರರು ನಿಮಗೆ ಬಿಲ್ ಮಾಡಲು ಅಥವಾ ಯಾವುದನ್ನೂ ನಾಶಮಾಡಲು ಸಾಧ್ಯವಾಗದೆ ನಿರ್ಮಿಸಬಹುದು.
ಸಂಸ್ಥೆ, ಅದರ ಸದಸ್ಯರು, ಅದರ ಸೈಟ್‌ಗಳು, ಅದರ ಬಿಲ್ಲಿಂಗ್, ಪ್ಲಾನ್ ಕ್ಯಾಟಲಾಗ್, ಟಿಕೆಟ್‌ಗಳು, ಅನುವಾದ ಸ್ಥಿತಿ ಮತ್ತು ಆಡಿಟ್ ಲಾಗ್ ಅನ್ನು ವೀಕ್ಷಿಸುತ್ತದೆ — ಮತ್ತು ಅದರಲ್ಲಿ ಯಾವುದನ್ನೂ ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಗೋಚರತೆಯನ್ನು ಬಯಸುವ ಕ್ಲೈಂಟ್, ಆಡಿಟರ್ ಅಥವಾ ಕೇವಲ ವೀಕ್ಷಿಸಬೇಕಾದ ಮಧ್ಯಸ್ಥಗಾರರಿಗೆ ಸರಿಯಾದ ಅನುಮತಿ.
ನೀವು ಪ್ರವೇಶಾವಕಾಶವನ್ನು ನಿಯೋಜಿಸುವ ಖಾತೆಗಳನ್ನು ವಶಪಡಿಸಿಕೊಳ್ಳುವುದು ಕಷ್ಟವಾಗಿದ್ದರೆ ಮಾತ್ರ ಪ್ರವೇಶವನ್ನು ನಿಯೋಜಿಸುವುದು ಸುರಕ್ಷಿತವಾಗಿರುತ್ತದೆ. ಖಾತೆಯಲ್ಲಿರುವ ಪ್ರತಿಯೊಬ್ಬ ವ್ಯಕ್ತಿಗೂ, ಪ್ರತಿಯೊಂದು ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲೂ ದೃಢೀಕರಣವು Keycloak ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಬೆಂಬಲ ಕಾರ್ಯವು ಕೆಲವೊಮ್ಮೆ ನಿಮ್ಮ ಖಾತೆಯ ಒಳಗೆ ಪರಿಶೀಲಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಆ ಪ್ರವೇಶವನ್ನು ಉಳಿದೆಲ್ಲವುಗಳಂತೆಯೇ ಅದೇ ಅನುಮತಿ ಮಾದರಿಯ ಮೂಲಕ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ — ಸಿಬ್ಬಂದಿಯು ಕೇವಲ ಸಿಬ್ಬಂದಿ ಸಂಸ್ಥೆಯಲ್ಲಿ ಇರುತ್ತಾರೆ, ನಿರ್ದಿಷ್ಟ ಸೀಮಿತ ಅನುಮತಿಗಳನ್ನು ಹೊಂದಿರುವ ಇಲಾಖೆಗಳಾಗಿ ಸಂಘಟಿತರಾಗಿದ್ದಾರೆ.
ಸಿಬ್ಬಂದಿಯನ್ನು ಬೆಂಬಲ, ಬಿಲ್ಲಿಂಗ್ ಮತ್ತು ಹಣಕಾಸು, ದುರುಪಯೋಗ ಮತ್ತು ನಂಬಿಕೆ-ಮತ್ತು-ಸುರಕ್ಷತೆ, ಮಾರಾಟ, ಆನ್‌ಬೋರ್ಡಿಂಗ್, ಎಂಜಿನಿಯರಿಂಗ್ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಗಳು, ಮಾರುಕಟ್ಟೆ ಮತ್ತು ನಿರ್ವಹಣೆ ಎಂದು ಗುಂಪು ಮಾಡಲಾಗಿದೆ. ಪ್ರತಿಯೊಂದು ಪಾತ್ರವು ನಿರ್ದಿಷ್ಟ ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಕ್ರಿಯೆಗಳನ್ನು ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಬ್ಬ ಏಜೆಂಟ್ ತನ್ನ ಕೆಲಸಕ್ಕೆ ಅಗತ್ಯವಿರುವ ನಿರ್ವಾಹಕ ಕನ್ಸೋಲ್‌ನ ಭಾಗವನ್ನು ಮಾತ್ರ ನೋಡುತ್ತಾನೆ ಮತ್ತು ಉಳಿದದ್ದನ್ನು ನೋಡುವುದಿಲ್ಲ.
Support Agent ಪಾತ್ರವು ನಿಖರವಾಗಿ ಇವುಗಳನ್ನು ನೀಡುತ್ತದೆ: ಗ್ರಾಹಕರನ್ನು ನೋಡುವುದು, ಟಿಕೆಟ್‌ಗಳನ್ನು ನೋಡುವುದು ಮತ್ತು ಉತ್ತರಿಸುವುದು, ಸೈಟ್‌ಗಳನ್ನು ನೋಡುವುದು, ಸೈಟ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದು ಮತ್ತು ಅದರ ಸಂಗ್ರಹವನ್ನು ತೆರವುಗೊಳಿಸುವುದು. ಇದು ಯಾವುದೇ ಬಿಲ್ಲಿಂಗ್ ಕಾನ್ಫಿಗರೇಶನ್, ಮರುಪಾವತಿಗಳು, ಯೋಜನೆ ಸಂಪಾದನೆ ಮತ್ತು ಫ್ಲೀಟ್ ನಿರ್ವಹಣೆಯನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ಏಜೆಂಟ್ ನಿರ್ವಹಿಸಬಹುದಾದ ಪರಿಹಾರ ಕ್ರಮವು ಆ ಪಾತ್ರಕ್ಕೆ ಸೀಮಿತವಾಗಿರುತ್ತದೆ, ಸದುದ್ದೇಶಗಳಿಗೆ ಅಲ್ಲ.
customer.impersonate ಅನುಮತಿಯು Manager ಪಾತ್ರದ ಭಾಗವಾಗಿರುವುದಿಲ್ಲ — ಇದನ್ನು Super Admin ಮಾತ್ರ ಹೊಂದಿರುತ್ತಾರೆ. ನಿಮ್ಮ ಪರವಾಗಿ ಸೆಶನ್ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ, ಯಾರು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದು ಎಂದಿಗೂ ಅಸ್ಪಷ್ಟವಾಗಿರದಂತೆ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ನಿರಂತರ ಪ್ರತಿರೂಪಣೆಯ (ಇಂಪರ್ಸನೇಶನ್) ಬ್ಯಾನರ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ.
ಪ್ರತಿಯೊಂದು ಸವಲತ್ತು ಪಡೆದ ಮತ್ತು ಆಡಳಿತಾತ್ಮಕ ಕ್ರಿಯೆಯು ಕರ್ತೃ, ಕ್ರಿಯೆ, ಗುರಿ, ಪೂರಕ ಮೆಟಾಡೇಟಾ, IP ವಿಳಾಸ ಮತ್ತು ಸಮಯದ ಮುದ್ರೆಯನ್ನು ದಾಖಲಿಸುವ ಕೇವಲ-ಸೇರ್ಪಡೆ ಮಾಡಬಹುದಾದ ಆಡಿಟ್ ಲಾಗ್‌ಗೆ ಸೇರ್ಪಡೆಗೊಳ್ಳುತ್ತದೆ — ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸಮಯ-ವಿಭಜಿತವಾಗಿರುತ್ತದೆ. ಮಾಲೀಕರು ಮತ್ತು ಓದಲು-ಮಾತ್ರ ಪ್ರವೇಶವಿರುವ ಸದಸ್ಯರು ತಮ್ಮ ಸಂಸ್ಥೆಯ ಲಾಗ್ ಅನ್ನು ತಾವೇ ಓದಬಹುದು.
ಸಿಬ್ಬಂದಿಯ ಸೂಕ್ಷ್ಮ ಮತ್ತು ಹಾನಿಕಾರಕ ಕ್ರಮಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಮೊದಲು ಹೆಚ್ಚುವರಿ ದೃಢೀಕರಣ ಅಥವಾ ಇಬ್ಬರು ವ್ಯಕ್ತಿಗಳ ಅನುಮೋದನೆಯ ಅಗತ್ಯವಿರಬಹುದು, ಮತ್ತು ಹೊಸ ವಿಭಾಗಗಳು ಹಾಗೂ ಪಾತ್ರಗಳು ಕೋಡ್ ಬದಲಾವಣೆಯ ಬದಲಿಗೆ ಕೇವಲ ಕಾನ್ಫಿಗರೇಶನ್ ಆಗಿರುತ್ತವೆ.
ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು, CI ಪೈಪ್‌ಲೈನ್‌ಗಳು, CLI, Terraform ಪೂರೈಕೆದಾರರು ಮತ್ತು AI ಏಜೆಂಟ್‌ಗಳು ಎಲ್ಲರೂ ಜನರಂತೆಯೇ ಅದೇ ಅನುಮತಿ ಮಾದರಿಯ ಮೂಲಕ ದೃಢೀಕರಿಸುತ್ತಾರೆ — ಯಾವುದೇ ಹಂಚಿಕೆಯ ಮಾನವ ರುಜುವಾತುಗಳಿಲ್ಲ, ಬಿಲ್ಡ್‌ಗೆ ಅಂಟಿಸಲಾದ ದೀರ್ಘಕಾಲೀನ ರಹಸ್ಯಗಳಿಲ್ಲ.
ಕೀಲಿಗಳು ಸಂಸ್ಥೆಗೆ ಸೇರಿರುತ್ತವೆ ಮತ್ತು ಅದೇ RBAC ಅನುಮತಿಗಳಿಗೆ ಜೋಡಿಸಲಾದ ಸೂಕ್ಷ್ಮ ವ್ಯಾಪ್ತಿಯನ್ನು ಹೊಂದಿರುತ್ತವೆ — ಕೇವಲ-ಓದಲು, ಬಿಲ್ಲಿಂಗ್, ಪ್ರಾವಿಷನಿಂಗ್. ಸದಸ್ಯರ ಸಂಪೂರ್ಣ ಖಾತೆಯನ್ನು ನೀಡುವ ಬದಲು ಪೈಪ್‌ಲೈನ್‌ಗೆ ಅಗತ್ಯವಿರುವ ನಿರ್ದಿಷ್ಟ ವ್ಯಾಪ್ತಿಯನ್ನು ಮಾತ್ರ ನೀಡಿ.
ಪರೀಕ್ಷಾ-ಮೋಡ್ ಮತ್ತು ಲೈವ್-ಮೋಡ್ ಕೀಗಳು ವಿಭಿನ್ನವಾಗಿವೆ, ಆದ್ದರಿಂದ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿರುವ ಏಕೀಕರಣವು ಆಕಸ್ಮಿಕವಾಗಿ ಅಥವಾ ನಕಲಿಸಲಾದ ಪರಿಸರ ವೇರಿಯೇಬಲ್ ಮೂಲಕ ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ನಾವು ಸೀಕ್ರೆಟ್‌ನ SHA-256 ಹ್ಯಾಶ್ ಮತ್ತು ಲುಕಪ್ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ — ಎಂದಿಗೂ ಮೂಲ ಕೀಯನ್ನು ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ. ರಚನೆಯ ಸಮಯದಲ್ಲಿ ಮಾತ್ರ ನೀವು ಕೀಯನ್ನು ಒಮ್ಮೆ ನೋಡುತ್ತೀರಿ. ಪ್ರತಿಯೊಂದು ಕೀಯು ಅದನ್ನು ಕೊನೆಯದಾಗಿ ಯಾವಾಗ ಬಳಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಬೇರೆ ಯಾವುದಕ್ಕೂ ತೊಂದರೆಯಾಗದಂತೆ ಅದನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಹಿಂಪಡೆಯಬಹುದು.
ನಮ್ಮ MCP ಸರ್ವರ್ ಯಾವುದೇ MCP-ಸಾಮರ್ಥ್ಯವಿರುವ ಏಜೆಂಟ್‌ಗೆ ನೈಸರ್ಗಿಕ ಭಾಷೆಯಲ್ಲಿ ನಿಮ್ಮ ಹೋಸ್ಟಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, OAuth 2.1 ನೊಂದಿಗೆ ದೃಢೀಕರಿಸಲ್ಪಟ್ಟಿದೆ ಮತ್ತು ನಿಮ್ಮ ಸಂಸ್ಥೆ ಹಾಗೂ RBAC ಪಾತ್ರಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸಲಾಗಿದೆ, ಪ್ರತಿ-ಟೂಲ್ಗೆ ರದ್ದುಗೊಳಿಸಬಹುದಾದ ಟೋಕನ್‌ಗಳು, ವಿನಾಶಕಾರಿ ಕ್ರಿಯೆಗಳ ಮೇಲೆ ದೃಢೀಕರಣ, ವೆಚ್ಚ ಮಿತಿಗಳು ಮತ್ತು ಸಂಪೂರ್ಣ ಆಡಿಟ್ ಲಾಗಿಂಗ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ.
ಖಾತೆ ಪ್ರವೇಶ ಮತ್ತು ಸರ್ವರ್ ಪ್ರವೇಶ ವಿಭಿನ್ನ ಸಮಸ್ಯೆಗಳಾಗಿವೆ. ಸೈಟ್-ಮಟ್ಟದ ರುಜುವಾತುಗಳನ್ನು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ, ಕನಿಷ್ಠ ಸವಲತ್ತುಗಳೊಂದಿಗೆ ನೀಡಲಾಗುತ್ತದೆ ಮತ್ತು ಒಬ್ಬ ಸಹಯೋಗಿಯ ಶೆಲ್ ಕೇವಲ ಒಂದು ಸೈಟ್‌ನ ಶೆಲ್ ಆಗಿರುವಂತೆ ಪ್ರತ್ಯೇಕಿಸಲಾಗುತ್ತದೆ.
ಏಕೈಕ ನಿರ್ವಾಹಕರು ಒಂದು ಸಂಸ್ಥೆ ಮತ್ತು ಒಂದು ಮಾಲೀಕ ಸದಸ್ಯತ್ವವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತಾರೆ, ಮತ್ತು ಯೋಜನೆಯೊಂದಕ್ಕಾಗಿ ಗುತ್ತಿಗೆದಾರರು ಬಂದಾಗ ಡೆವಲಪರ್ ಪಾತ್ರವನ್ನು ಸೇರಿಸುತ್ತಾರೆ. ಯೋಜನೆಯು ಮುಕ್ತಾಯಗೊಂಡಾಗ, ಸದಸ್ಯತ್ವವನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು ಅವರ ಸೈನ್-ಇನ್ ತಕ್ಷಣವೇ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ — ಬದಲಾಯಿಸಲು ಯಾವುದೇ ಹಂಚಿಕೆಯ ರುಜುವಾತುಗಳು ಉಳಿಯುವುದಿಲ್ಲ.
ಏಜೆನ್ಸಿಯೊಂದು ಸಂಸ್ಥೆಯ ವೃಕ್ಷ ರಚನೆಯನ್ನು ಬಳಸುತ್ತದೆ. ಪ್ರತಿಯೊಬ್ಬ ಕ್ಲೈಂಟ್ ತಮ್ಮ ಸೈಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ತನ್ನದೇ ಆದ ಉಪ-ಸಂಸ್ಥೆಯನ್ನು ಪಡೆಯುತ್ತಾರೆ ಮತ್ತು ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ಜನರಿಗೆ ಅಲ್ಲಿ ಸದಸ್ಯತ್ವಗಳು ದೊರೆಯುತ್ತವೆ — ಕೇವಲ ವೀಕ್ಷಿಸಲು ಬಯಸುವ ಪಾಲುದಾರರಿಗೆ ಓದಲು-ಮಾತ್ರ ಅವಕಾಶ, ಸ್ವಯಂ-ಸೇವೆ ಬಯಸುವ ಕ್ಲೈಂಟ್‌ಗೆ ಮಾಲೀಕರ ಸ್ಥಾನಮಾನ. ನಿಮ್ಮ ಸಿಬ್ಬಂದಿ ವೃಕ್ಷ ರಚನೆಯ ಉನ್ನತ ಹಂತಗಳಲ್ಲಿ ಸದಸ್ಯತ್ವಗಳನ್ನು ಹೊಂದಿರುತ್ತಾರೆ ಮತ್ತು ಪೋರ್ಟ್‌ಫೋಲಿಯೊವನ್ನು ವೀಕ್ಷಿಸುತ್ತಾರೆ; ಕ್ಲೈಂಟ್ ತನ್ನ ಸ್ವಂತ ಶಾಖೆಯನ್ನು ಮಾತ್ರ ನೋಡುತ್ತಾರೆ ಮತ್ತು Row-Level Security ಇದನ್ನು ಕೇವಲ ಭರವಸೆಯಾಗಿರಿಸದೆ ವಾಸ್ತವವನ್ನಾಗಿ ಮಾಡುತ್ತದೆ.
ಮರುಮಾರಾಟಗಾರರು ಅದೇ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ, ಒಂದು ಹಂತ ಮೇಲಕ್ಕೆ: ಮರುಮಾರಾಟಗಾರ ಸಂಸ್ಥೆಯು ಕ್ಲೈಂಟ್ ಸಂಸ್ಥೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ಸದಸ್ಯರು, ಬಿಲ್ಲಿಂಗ್ ವೀಕ್ಷಣೆ ಮತ್ತು ಸೈಟ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಅದೇ ಮೂಲ ಅಂಶವು ಉಪ-ಖಾತೆಗಳು, ಏಜೆನ್ಸಿ ತಂಡಗಳು ಮತ್ತು ಮರುಮಾರಾಟಗಾರರ ಶ್ರೇಣಿಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ — ಇವುಗಳಲ್ಲಿ ಯಾವುದಕ್ಕೂ ಪ್ರತ್ಯೇಕವಾದ, ದುರ್ಬಲವಾದ ಕಾರ್ಯವಿಧಾನವಿಲ್ಲ.
ಕಾರ್ಡ್ ಇಲ್ಲದ 14 ದಿನಗಳ ಉಚಿತ ಪ್ರಯೋಗದಲ್ಲಿ ಎಲ್ಲವೂ ಲಭ್ಯವಿದೆ. ಪಾವತಿ ವಿವರಗಳಿಲ್ಲದೆ ಸೈನ್ ಅಪ್ ಮಾಡಿ, ಸಹೋದ್ಯೋಗಿಯನ್ನು ಆಹ್ವಾನಿಸಿ, ಪ್ರತಿಯೊಂದು ಪಾತ್ರವು ಯಾವುದನ್ನು ಪ್ರವೇಶಿಸಬಹುದು ಮತ್ತು ಯಾವುದನ್ನು ಪ್ರವೇಶಿಸಲಾಗುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ವೀಕ್ಷಿಸಿ ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ ಆಡಿಟ್ ಲಾಗ್ ಅನ್ನು ಮರಳಿ ಓದಿ.
ಪ್ರಸ್ತುತ ಸದಸ್ಯತ್ವವು ಒಂದು ಸಂಸ್ಥೆ ಮತ್ತು ಅದರ ಕ್ರಮಾನುಗತ ರಚನೆಯಲ್ಲಿರುವ ಎಲ್ಲದಕ್ಕೂ ತನ್ನ ಪಾತ್ರದ ಪ್ರವೇಶವನ್ನು ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಸೈಟ್ ಸೆಟ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುವ ಮಾರ್ಗವೆಂದರೆ ಸಂಸ್ಥೆಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು — ಆ ಸೈಟ್‌ಗಳನ್ನು ಅವುಗಳದೇ ಆದ ಅಧೀನ ಸಂಸ್ಥೆಯಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಸದಸ್ಯತ್ವವನ್ನು ಅಲ್ಲಿ ನೀಡಿ. ಇದು ಏಜೆನ್ಸಿಗಳು ಮತ್ತು ಮರುಮಾರಾಟಗಾರರಿಗೆ ಒಂದು ಸೂಕ್ತ ಮಾದರಿಯಾಗಿದೆ, ಏಕೆಂದರೆ ಇಲ್ಲಿ ಪ್ರತಿಯೊಬ್ಬ ಗ್ರಾಹಕರು ಈಗಾಗಲೇ ತಮ್ಮದೇ ಆದ ಪ್ರತ್ಯೇಕ ಮಿತಿಯನ್ನು ಬಯಸುತ್ತಾರೆ. ಸದಸ್ಯತ್ವದ ಆಧಾರದ ಮೇಲೆ ಸಂಪನ್ಮೂಲ ವ್ಯಾಪ್ತಿ ನಿಗದಿಪಡಿಸುವುದು, ಅಂದರೆ ಒಂದೇ ಸಂಸ್ಥೆಯೊಳಗಿನ ನಿರ್ದಿಷ್ಟ ಸೈಟ್‌ಗಳಿಗೆ ಒಂದೇ ಸದಸ್ಯತ್ವವನ್ನು ನಿಗದಿಪಡಿಸುವುದು, ಯೋಜಿತ ಸುಧಾರಣೆಯಾಗಿದೆಯೇ ಹೊರತು ಪ್ರಸ್ತುತ ಲಭ್ಯವಿರುವ ಸೌಲಭ್ಯವಲ್ಲ.
Developer ಪಾತ್ರವು ಸೈಟ್ ಅಳಿಸುವಿಕೆ ಅಥವಾ ಸೈಟ್ ಅಮಾನತುಗೊಳಿಸುವಿಕೆಯನ್ನು ಒಳಗೊಂಡಿರುವುದಿಲ್ಲ — ಆ ಕೀಲಿಗಳು Owner ಪಾತ್ರಕ್ಕೆ ಸೇರಿರುತ್ತವೆ. ಇದು ಸೈಟ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸುವುದು ಮತ್ತು ರಚಿಸುವುದು, ಸೇವೆಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದು, ಕ್ಯಾಶ್ ತೆರವುಗೊಳಿಸುವುದು, API ಕೀಲಿಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ಮತ್ತು ಟಿಕೆಟ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನೀಡುತ್ತದೆ. ನಿಯೋಜನೆ (deployment) ಮತ್ತು push-to-live ಅನುಮತಿಗಳು ಸಹ Developer ಅನುದಾನದ ಭಾಗವಾಗಿರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ಪ್ರಚಾರ ಮಾಡುವುದು ಖಾತೆಯ ಮಾಲೀಕರ ಬಳಿಯೇ ಇರುತ್ತದೆ. ಇದನ್ನು ಸ್ಟೇಜಿಂಗ್‌ನೊಂದಿಗೆ ಜೋಡಿಸಿ, ಇದರಿಂದ ಬಿಲ್ಡ್ ಕೆಲಸವು ಮೊದಲಿನಿಂದಲೇ ಲೈವ್ ಸೈಟ್‌ನ ಹೊರಗೆ ನಡೆಯುತ್ತದೆ.
ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಸಿಬ್ಬಂದಿ ಪಾತ್ರದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದು ಪಾತ್ರವು ಅನುಮತಿ ಕೀಲಿಗಳ ಕಿರಿದಾದ ಗುಂಪಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಒಬ್ಬ Support Agent ನಿಮ್ಮ ಖಾತೆ ಮತ್ತು ಸೈಟ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸಬಹುದು, ನಿಮ್ಮ ಟಿಕೆಟ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸಬಹುದು ಮತ್ತು ಪ್ರತ್ಯುತ್ತರಿಸಬಹುದು, ಸೈಟ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಬಹುದು ಮತ್ತು ಅದರ ಸಂಗ್ರಹವನ್ನು (cache) ತೆರವುಗೊಳಿಸಬಹುದು — ಮತ್ತು ಬಿಲ್ಲಿಂಗ್ ಕಾನ್ಫಿಗರೇಶನ್, ಮರುಪಾವತಿಗಳು, ಯೋಜನೆಗಳು ಅಥವಾ ಫ್ಲೀಟ್ ಅನ್ನು ಮುಟ್ಟಲು ಸಾಧ್ಯವಿಲ್ಲ. ಗ್ರಾಹಕರಾಗಿ ಸೈನ್ ಇನ್ ಮಾಡುವುದು Super Admin ಮಾತ್ರ ಹೊಂದಿರುವ ಪ್ರತ್ಯೇಕ ಅನುಮತಿಯಾಗಿದೆ, ಮತ್ತು ಇದು ಸಂಭವಿಸಿದಾಗ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ನಿರಂತರ ಪ್ರತಿರೂಪಣ (impersonation) ಬ್ಯಾನರ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಸವಲತ್ತು ಪಡೆದ ಕ್ರಿಯೆಯನ್ನು ಆಕ್ಟರ್, ಕ್ರಿಯೆ, ಗುರಿ, IP ಮತ್ತು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ನೊಂದಿಗೆ ಆಡಿಟ್ ಲಾಗ್ನಲ್ಲಿ ದಾಖಲಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ಸಂಸ್ಥೆಯ ಲಾಗ್ ಅನ್ನು ನೀವೇ ಓದಬಹುದು.
ಸದಸ್ಯತ್ವವನ್ನು ತೆಗೆದುಹಾಕಿ ಮತ್ತು ಆ ಸಂಸ್ಥೆಗೆ ಅವರ ಪ್ರವೇಶವು ಕೊನೆಗೊಳ್ಳುತ್ತದೆ — ಅವರು ಇನ್ನೂ ತಮ್ಮದೇ ಆದ ಗುರುತನ್ನು ಹೊಂದಿರುತ್ತಾರೆ, ಆದರೆ ನಿಮ್ಮ ಖಾತೆಯಲ್ಲಿ ಯಾವುದೇ ಪಾತ್ರ ಮತ್ತು ಅನುಮತಿಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. API ಕೀಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಹಿಂಪಡೆಯಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಬೇರೆ ಯಾವುದಕ್ಕೂ ತೊಂದರೆಯಾಗದಂತೆ ಪೈಪ್‌ಲೈನ್ ಕೀಲಿಯನ್ನು ಕಡಿತಗೊಳಿಸಬಹುದು. ನೀವು SAML ಏಕ ಸೈನ್-ಆನ್ ಬಳಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಗುರುತು ಒದಗಿಸುವವರಲ್ಲಿ ಡಿಪ್ರೊವಿಷನಿಂಗ್ ಸೈನ್-ಇನ್ ಅನ್ನು ಕೇಂದ್ರೀಯವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ. SSH ಕೀಗಳಂತಹ ಸೈಟ್-ಮಟ್ಟದ ರುಜುವಾತುಗಳನ್ನು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ಹಿಂಪಡೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ತೆಗೆದುಹಾಕುವಿಕೆಯನ್ನು ಆಡಿಟ್ ಲಾಗ್ ಮಾಡಲಾಗುತ್ತದೆ.
ಇಲ್ಲ — ಆದರೆ ಅದಕ್ಕೆ ಕಾರಣವನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುವುದು ಉಪಯುಕ್ತವಾಗಿದೆ. API ಕೀಗಳು ಸಂಸ್ಥೆಗೆ ಸೇರಿದವಾಗಿರುತ್ತವೆಯೇ ಹೊರತು ಪ್ರತ್ಯೇಕ ಸದಸ್ಯರಿಗಲ್ಲ, ಮತ್ತು ಅವು ಒಂದೇ ಅನುಮತಿ ಕ್ಯಾಟಲಾಗ್‌ಗೆ ಜೋಡಿಸಲಾದ ತಮ್ಮದೇ ಆದ ವಿವರವಾದ ಸ್ಕೋಪ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಆದ್ದರಿಂದ ಒಬ್ಬ ವ್ಯಕ್ತಿಗೆ ಕೀಲಿಯನ್ನು ಹಸ್ತಾಂತರಿಸುವ ಬದಲು, ಆ ಕೆಲಸಕ್ಕೆ ಅಗತ್ಯವಿರುವ ಅತ್ಯಂತ ಕಿರಿದಾದ ಸ್ಕೋಪ್‌ನೊಂದಿಗೆ ಅದು ಮಾಡುವ ಕೆಲಸಕ್ಕಾಗಿ ನೀವು ಕೀಲಿಯನ್ನು ರಚಿಸುತ್ತೀರಿ ಮತ್ತು ಕೆಲಸ ಮುಗಿದ ನಂತರ ಆ ಕೀಲಿಯನ್ನು ರದ್ದುಗೊಳಿಸುತ್ತೀರಿ. ಸೀಕ್ರೆಟ್‌ನ ಹ್ಯಾಶ್ ಅನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಕೀಲಿಯು ಅದನ್ನು ಕೊನೆಯದಾಗಿ ಯಾವಾಗ ಬಳಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಬಳಕೆಯಾಗದ ಕೀಗಳನ್ನು ಹುಡುಕುವುದು ಮತ್ತು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಸುಲಭವಾಗಿದೆ.
ಹೌದು. ನಮ್ಮ MCP ಸರ್ವರ್ OAuth 2.1 ಮೂಲಕ ಏಜೆಂಟ್ಗಳನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ-ಟೂಲ್ಗೆ ಹಿಂಪಡೆಯಬಹುದಾದ ಟೋಕನ್ಗಳೊಂದಿಗೆ ನಿಮ್ಮ ಸಂಸ್ಥೆ ಮತ್ತು ನಿಮ್ಮ RBAC ಪಾತ್ರಕ್ಕೆ ಅವುಗಳನ್ನು ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಸಾರಾಸಗಟು ಪ್ರವೇಶದ ಬದಲಿಗೆ ನಿರ್ದಿಷ್ಟ ಸಾಮರ್ಥ್ಯವನ್ನು ನೀಡುತ್ತೀರಿ. ವಿನಾಶಕಾರಿ ಕ್ರಿಯೆಗಳಿಗೆ ದೃಢೀಕರಣದ ಅಗತ್ಯವಿರುತ್ತದೆ, ವೆಚ್ಚದ ಮಿತಿಗಳು ಅನ್ವಯಿಸುತ್ತವೆ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಕ್ರಿಯೆಯೂ ಮಾನವ ಚಟುವಟಿಕೆಯಂತೆಯೇ ಅದೇ ಆಡಿಟ್ ಲಾಗ್ನಲ್ಲಿ ದಾಖಲಾಗುತ್ತದೆ.
Postgres Row-Level Security ಸ್ವತಃ ಡೇಟಾಬೇಸ್ನಲ್ಲಿಯೇ ಕ್ವೆರಿಗಳನ್ನು ಕಾಲರ್ನ ಸಂಸ್ಥೆಯ ಉಪವೃಕ್ಷಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ, ಇದರಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್-ಮಟ್ಟದ ಫಿಲ್ಟರ್ ಕೇವಲ ಏಕೈಕ ರಕ್ಷಣೆಯಾಗಿರದೇ ಬಹುಸ್ತರದ ರಕ್ಷಣೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗಿರುವ ದಾಖಲೆಗಳ ವಿನಂತಿಗಳು ಅನುಮತಿ ದೋಷದ ಬದಲಿಗೆ ಲಭ್ಯವಿಲ್ಲ ಎಂಬ ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಯಾವ ಡೇಟಾ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂಬುದು ಬಹಿರಂಗವಾಗುವುದಿಲ್ಲ. ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ, CageFS ಮೂಲಕ ಪ್ರತಿ ಸೈಟ್ ಪ್ರತ್ಯೇಕತೆಯು ಪ್ರತಿಯೊಬ್ಬ ಟೆನೆಂಟ್ನ ಶೆಲ್ ಮತ್ತು ಫೈಲ್ಗಳನ್ನು ಅವರದೇ ಸೈಟ್ಗೆ ಸೀಮಿತವಾಗಿರಿಸುತ್ತದೆ.
ಹೌದು. 14 ದಿನಗಳ ಪ್ರಯೋಗಾವಧಿಗೆ ಕಾರ್ಡ್ ಅಗತ್ಯವಿಲ್ಲ — ಯಾವುದೇ ಪಾವತಿ ವಿವರಗಳಿಲ್ಲ, ಯಾವುದೇ ಬದ್ಧತೆಯಿಲ್ಲ — ಮತ್ತು ಐದು ಸೈಟ್‌ಗಳವರೆಗೆ Footprint-Free ಹೋಸ್ಟಿಂಗ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ. ನೀವು ಬದ್ಧರಾಗುವ ಮೊದಲು ಸಹೋದ್ಯೋಗಿಯನ್ನು ಆಹ್ವಾನಿಸಲು, ಪಾತ್ರವನ್ನು ನಿಯೋಜಿಸಲು ಮತ್ತು ಗಡಿಗಳು ನಿಮಗೆ ಅಗತ್ಯವಿರುವಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಇದು ಸಾಕಾಗುತ್ತದೆ.
ಕಾರ್ಡ್-ಮುಕ್ತ 14-ದಿನಗಳ ಪ್ರಾಯೋಗಿಕ ಅವಧಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ, ಯಾರನ್ನಾದರೂ ಆಹ್ವಾನಿಸಿ ಮತ್ತು ಅನುಮತಿ ಮಾದರಿಯು ತನ್ನ ಕೆಲಸವನ್ನು ಹೇಗೆ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ವೀಕ್ಷಿಸಿ — ನೀವು ಹೆಸರಿಸಬಹುದಾದ ಪಾತ್ರಗಳು, ನೀವು ಹಿಂಪಡೆಯಬಹುದಾದ ವ್ಯಾಪ್ತಿಗಳು ಮತ್ತು ಯಾರು ಏನು ಮಾಡಿದರು ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ತಿಳಿಸುವ ಆಡಿಟ್ ಲಾಗ್.
ಉಚಿತವಾಗಿ ಪ್ರಾರಂಭಿಸಿ