azure blob storage

Azure File Sharing Architecture Report

Executive Summary

This document evaluates different approaches for securely sharing CSV files with external partner organizations through our multi-tenant web application. The key requirement is to share files that auto-expire after 30 days while preventing unauthorized access through email forwarding.

Business Context

• Current Setup: Multi-tenant web application with Microsoft Graph API permissions from partner organizations
• Requirement: Share CSV files with external users from partner organizations
• Security Concern: Prevent unauthorized access if emails containing file links are forwarded
• Compliance: Files must automatically expire/delete after 30 days
• Architecture: Cross-tenant scenario (our storage account in our tenant, external users in their own tenants)

Technical Approaches Evaluated

1. SAS (Shared Access Signature) Tokens - ❌ Not Recommended

Description: Generate time-limited URLs that provide direct access to Azure Storage files.

Types of SAS:

• Regular SAS: Created using storage account keys
• User Delegation SAS: Created using Azure AD credentials (more secure)
• Account SAS: Grants access to entire storage account
• Service SAS: Scoped to specific service (Blob, Queue, Table, File)

Implementation:

1. Generate SAS token with 30-day expiry
2. Email SAS URL directly to users
3. Users access files directly from Azure Storage

Advantages:

• Simple implementation
• Direct access to Azure Storage (good performance)
• Built-in expiry mechanism

Critical Disadvantages:

• Forwarding Risk: Anyone who receives forwarded email can access files
• No identity verification: Bearer token approach
• Limited audit trail: Difficult to track who actually accessed files
• No granular permission control: Access is binary (have URL = access)

Verdict: ❌ Rejected due to security concerns

2. Azure AD Authentication + Web App Gateway - ✅ Recommended

Description: External users authenticate through our multi-tenant web app, which then serves files directly from storage.

Implementation:

1. User clicks link in email → Redirected to our web app
2. User authenticates using their organizational credentials (Azure AD)
3. Our app validates user is from authorized organization
4. Our app reads file from storage using managed identity
5. Our app serves file directly to authenticated user

Authentication Flow:

• External Users: OAuth 2.0 through multi-tenant Azure AD
• App to Storage: Managed Identity with Storage Blob Data Reader role
• File Lifecycle: Azure Blob Lifecycle Management (30-day auto-deletion)

Advantages:

• ✅ No forwarding risk: Users must authenticate to access files
• ✅ Identity-based security: Leverages existing organizational credentials
• ✅ Full audit trail: Complete logging of who accessed what
• ✅ Granular control: Can restrict access by user/organization
• ✅ Leverages existing infrastructure: Uses current multi-tenant app setup
• ✅ Microsoft's recommended approach: Follows security best practices

Disadvantages:

• Uses app bandwidth for file serving
• Slightly more complex implementation
• App becomes bottleneck for large files

Performance Considerations:

• Suitable for typical CSV file sizes
• May impact app performance under heavy concurrent usage

3. Hybrid Approach: Azure AD + Dynamic SAS Generation - ✅ Alternative Option

Description: Users authenticate through web app, which then generates short-lived SAS tokens for direct storage access.

Implementation:

1. User clicks link in email → Redirected to our web app
2. User authenticates using organizational credentials
3. Our app validates permissions for specific file
4. Our app generates short-lived SAS token (15-30 minutes)
5. User downloads directly from Azure Storage using SAS token

Advantages:

• ✅ No forwarding risk: Authentication required before SAS generation
• ✅ Better performance: Direct downloads from Azure Storage
• ✅ Scalability: App only handles authentication, not file serving
• ✅ Cost efficiency: Lower bandwidth costs for app
• ✅ Identity-based security: Maintains authentication requirements

Disadvantages:

• More complex implementation (SAS generation logic)
• Slightly larger attack surface (SAS tokens exist, even if short-lived)

Alternative Approaches Considered and Rejected

Azure AD B2B (Guest Users)

Why Rejected: Requires manual invitation process and guest user management overhead for each partner organization user.

Direct Azure AD Authentication to Storage

Why Rejected: Complex cross-tenant configuration required since our storage is in our tenant while external users are in their own tenants.

Shared Key Authorization

Why Rejected: Requires sharing sensitive storage account keys; not suitable for external user scenarios.

Technical Architecture Details

Storage Configuration

• Service: Azure Blob Storage
• Lifecycle Management: Automatic deletion after 30 days
• Access Control: Role-Based Access Control (RBAC)
• Required Role: Storage Blob Data Reader (for app's managed identity)

Authentication Infrastructure

• Identity Provider: Microsoft Entra ID (formerly Azure AD)
• App Registration: Multi-tenant configuration
• Token Type: OAuth 2.0 access tokens
• Cross-tenant Support: Built-in multi-tenant capabilities

Security Features

• Encryption: HTTPS for all communications
• Audit Logging: Full request/response logging
• Identity Verification: Organizational credential requirements
• Permission Scoping: Granular access control per user/organization

Recommendations

Primary Recommendation: Azure AD + Web App Gateway

Rationale:

• Addresses all security requirements
• Leverages existing multi-tenant infrastructure
• Provides complete audit trail
• Follows Microsoft security best practices
• Suitable for typical CSV file sharing scenarios

Implementation Priority: High

Secondary Option: Hybrid Approach

When to Consider:

• Large file sizes (>10MB)
• High concurrent usage expected
• Performance optimization is critical

Implementation Priority: Medium (consider for future optimization)

Implementation Roadmap

Phase 1: Core Implementation (2-3 weeks)

1. Configure Azure Blob Lifecycle Management (30-day deletion)
2. Set up managed identity for web app
3. Implement authentication endpoint for external users
4. Create file serving endpoint with permission validation
5. Update email templates with web app links

Phase 2: Optimization (1-2 weeks)

1. Add comprehensive logging and monitoring
2. Implement file access analytics
3. Add user-friendly error handling
4. Performance testing and optimization

Phase 3: Future Enhancements (Optional)

1. Consider hybrid approach if performance issues arise
2. Add file preview capabilities
3. Implement bulk download features

Risk Assessment

Security Risks: Low

• Authentication required for all access
• No direct storage URLs in emails
• Complete audit trail
• Automatic file expiry

Performance Risks: Low-Medium

• App bandwidth usage for file serving
• Potential bottleneck under high load
• Mitigated by typical CSV file sizes

Implementation Risks: Low

• Leverages existing authentication infrastructure
• Well-documented Azure services
• Clear migration path from current setup

Cost Implications

Storage Costs

• Standard Azure Blob Storage pricing
• Lifecycle management included
• Minimal cost impact

Compute Costs

• Slight increase in app compute usage for file serving
• Offset by improved security and compliance

Development Costs

• Estimated 3-4 weeks development time
• Leverages existing team Azure expertise

Conclusion

The Azure AD Authentication + Web App Gateway approach provides the optimal balance of security, functionality, and implementation simplicity for our use case. It eliminates the email forwarding security risk while leveraging our existing multi-tenant infrastructure and following Microsoft's recommended security practices.

The hybrid approach should be considered as a future optimization if performance requirements change or file sizes significantly increase.