AWSでオンラインストレージを作ろう(ownCloud)

Posted on | Edited on | In

どうしてこんなもんやる？

勤め先は事業会社で、各部署は頻繁的に社外の業者とデータやりとりする必要があるが、いままで共通ツールがなく、GoogleDriveなどの無料サービスを利用されていた。
しかし、これっていいのかというと、もちろんよくないです。
情報セキュリティの視点からも、あり得ないやり方ですね。
市販のサービスやソフトウェアを一通り検討したあと、やはり自社構築の方がメリットが大きので、今回AWS利用し、オンラインストレージを作ることになりました。

構成

完成品
ざっとこういう感じです、以上。

……と言いたいところですが、ダメですねw
簡単というと、

  1. システム全体はAWSのEC2二台を立ち上げそれぞれownCloudのAMIを適用させる。
  2. ALBも立ち上げ、二台EC2をグループに入れる。
  3. EC2内部いじる（ownCloud）
  4. RDSいじる(ownCloudのDBとして利用,MySQL)
  5. S3バケットつくる(実際のデータ格納場所)
  6. ElasticSearchServiceいじる(accesslog収集、kibanaで描画)
  7. Lambdaいじる(S3で格納してるownCloudのaccesslogをElasticSearchServiceに)
  8. ルートテーブル、セキュリティグループとACLいじる(ALBのセキュリティグループでアクセスできるIPの制限をかける)
  9. ドメイン確保、レコード登録

どう？簡単しょ？w

ダメだ、わからんよーセンセイ！

じゃ、実際ユーザーのリクエストの流れに沿って、シナリオを説明しますー
イメージ図

  • ユーザーアクセスが来たら、まずALBに到達、ドメイン利用したアクセスだけ許可、直接EC2のパブリックIPを叩いても、無反応だけ。プラス、強制的にHTTPSにリダイレクト
  • 実際にEC2にたどり着く（どのEC2に接続させるのは、ALBの判断で）
  • ownCloudのユーザー名とPWを利用し、ログイン。（ユーザー情報はEC2ローカルではなく、RDSに保存）
  • ownCloudのストレージスペースもEC2ローカルではなく、S3のバケットに指定
  • RDSはアクセスソースを限定
  • IP指定で、SSHできるソースも限定
  • 必要であれば、システムにアクセス可能なソースIPも限定できる（ALBで）

この構成のメリットは？

  • 各パーツ使い捨て、データはAWSサービスを利用し、永久化した
  • 基本AWSのサービスを利用するので、運用が楽
  • システムフルコントロールは自社把握、カスタマイズ自由
  • 主流なOSSを利用し、google先生に聞けば、色々資料が出てくるはず
  • 費用は市販サービスより大幅に低減