20200802のAWSに関する記事は10件です。

Amazon Personalize(AWS) と Recommendations AI(GCP) の機能の比較

概要

Amazon PersonalizeRecommendations AI のどちらを利用するかを迷ったときに、二つをわかりやすく比較できたらどちらを利用するかの意思決定がしやすいと思ったので簡単ですがまとめてみました。

アルゴリズム

アルゴリズムのタイプ 具体的なアルゴリズム
Amazon Personalize USER_PERSONALIZATION

あなたにおすすめ
HRNN
HRNN-Metadata
HRNN-Coldstart
Popularity-Count
PERSONALIZED_RANKING

与えたリストをパーソナライズして並び替える
Personalized-Ranking
RELATED_ITEMS

関連アイテム
SIMS
Recommendations AI Others you may like

表示中のある商品の次に購入しそうな商品
アルゴリズムの選択なし

下記のカスタマイズ可能
・最適化目標
・価格のランキング
・多様性
・パーソナライズの無効化
"Frequently bought together"(shopping cart expansion)

一緒にカートに入る商品
アルゴリズムの選択なし

下記のカスタマイズ可能
・最適化目標
Recommended for you

あなたにおすすめ
アルゴリズムの選択なし

下記のカスタマイズ可能
・最適化目標
・価格のランキング
・多様性
Recently viewed

最近閲覧したアイテム
アルゴリズムの選択なし

必要なデータ

必要なデータ 必須フィールド
Amazon Personalize ユーザー USER_ID
プラス最低1つの任意のフィールド
アイテム ITEM_ID
プラス最低1つの任意のフィールド
インタラクション USER_ID
ITEM_ID
TIMESTAMP
Recommendations AI カタログ id
categoryHierarchies
title
productMetadata.currencyCode
ユーザーイベント eventType
userInfo
eventDetail
productEventDetail
eventTime
eventSource
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

React hooks + Django RestFrameworkで簡単な欲しいものリストを作成

制作物について

ReactとDjango RestFrameworkの勉強のアウトプットとして非常に簡単な欲しいものリストアプリを作成しました。
バックエンドはAWS EC2にnginx環境を構築してデプロイ、フロントエンドはGithubのソースコードをS3に自動デプロイされるようにしています。
ソースコード
バックエンド 
https://github.com/s-amano/wishlist2
フロントエンド
https://github.com/s-amano/wishlist-frontend

アプリのURL
http://dbs94qexekbu1.cloudfront.net/
サンプルユーザーとして

アドレス:sample@gmail.com
パスワード:sample

でログインできます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

React hooks + Django RestFrameworkで欲しいものリストを作成

制作物について

ReactとDjango RestFrameworkの勉強のアウトプットとして非常に簡単な欲しいものリストアプリを作成しました。
バックエンドはAWS EC2にnginx環境を構築してデプロイ、フロントエンドはGithubのソースコードがS3に自動デプロイされるようにしています。
ソースコード
バックエンド 
https://github.com/s-amano/wishlist2
フロントエンド
https://github.com/s-amano/wishlist-frontend

アプリのURL
http://dbs94qexekbu1.cloudfront.net/
サンプルユーザーとして

アドレス:sample@gmail.com
パスワード:sample

でログインできます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amplify Frameworkの新しい認証UIコンポーネント(@aws-amplify/ui-react)を試そう

Amplify Frameworkとは

AWSがOSSとして提供している開発プラットフォーム。CLIでコマンドを叩くだけで認証やAPI、ストレージなどをAWS上にいい感じに構築してくれるスグレモノ。

最初の環境構築方法などは他の記事やサイトに書かれているのでそちらを参照していただきたい。

ただし、今回は
npm install aws-amplify-react
でaws-amplify-reactをReactアプリに組み込むことはせず、代わりに
npm install @aws-amplify/ui-react
を叩いて@aws-amplify/ui-reactを使用する。

認証画面の表示がおかしい・・・

本題に進む前にAmplify Frameworkを触っていて起きたことについて少しだけ書くと、
数多ある「Amplify Frameworkで認証画面を爆速で作ってみよう」系の記事を参考に
胸を躍らせながらAmplifyのコマンドを叩いてAWS環境を構築し、クライアントにパッケージを入れ、
いざnpm startを快音高らかに叩いた時に悲劇が起きた。

Failed_Auth

なにこれ・・・?

やべぇ・・・同じ手順で進めたはずが、クソださ認証画面を生み出してしまった。
何か間違えてたかと虱潰しに手順を確認するも特に異常なし。
途方に暮れながらGoogle先生にお伺いを立てていると天啓が届いた。

「それレガシーですよ」

公式ドキュメントではすでにaws-amplify-reactはLegacyと書かれているではないですか!(知らんかった・・・)

AWSのブログを見ると4月にはすでに発表されてるじゃないですか!(知らんかった・・・)

というわけで自分の無知に深く恥入りながらも、早速@aws-amplify/ui-reactを使って認証機能を作っていきましょうという次第であります。

(画面が変になったのはこのLegacyのせいなのかは実はちょっとハッキリしていません・・・(小声))

まずは基本のAmplifyAuthenticator

App.js
import React from 'react';
import Amplify from 'aws-amplify';
import { AmplifyAuthenticator } from '@aws-amplify/ui-react'; 
import awsconfig from './aws-exports';

Amplify.configure(awsconfig);

const App = () => (
  <AmplifyAuthenticator>
    <div>
      My App
    </div>
  </AmplifyAuthenticator>
);

export default App;

実装はとてもシンプルで@aws-amplify/ui-reactからAmplifyAuthenticatorをApp.jsにインポートして
認証通過後の画面要素を挟んであげるだけ。

SignIn画面

SignInPage1

SignUp画面

SignUpPage1

これだけで冒頭でお見せしたクソださ認証画面ではなく、ちゃんと綺麗な認証画面が出来上がった。とりあえず一安心。

入力項目をカスタマイズ

@aws-amplify/ui-reactではSign-inやSign-upの入力項目や必須か否かをカスタマイズすることができる。

まずはSign-in画面のUsernameのカスタマイズから。

デフォルトでは任意のUsernameを入力することになっているが、ここでメールアドレスを利用可能にする。

まずはCognitoの認証方式でメールアドレスをUsernameとして利用できるようにしておく。(参考サイト

Amplify FrameworkのCLIですでにメールアドレスをUsernameとして利用可能にしておいた場合は設定不要だ。

あとは以下のように先ほど書いたAmplifyAuthenticatorのusernameAliasプロパティに"email"を渡してあげればOK。

App.js
const App = () => (
  <AmplifyAuthenticator usernameAlias="email"> {/* <- ここで設定 */}
    <div>
      My App
    </div>
  </AmplifyAuthenticator>
);

Sign-in2

先ほどのSing-in画面と比べてUsernameの項目がEmail Addressに変更されている。
ここを電話番号にしたい場合はCognitoの設定後にusernameAliasに"phone_number"を渡すことで実現できる。

次にSign-upの入力項目が多すぎるなと感じたので減らしてみよう。

App.js
import { AmplifyAuthenticator, AmplifySignUp } from '@aws-amplify/ui-react';

まずは@aws-amplify/ui-reactからAmplifyAuthenticatorに加えてAmplifySignUpをインポート。

App.js
const App = () => (
  <AmplifyAuthenticator>
    <AmplifySignUp
      slot="sign-up"
      usernameAlias="email"
      formFields={[
        {
          type: "email",
          label: "Email address",
          placeholder: "Enter your email address",
          required: true,
        },
        {
          type: "password",
          label: "Password",
          placeholder: "Enter your password",
          required: true,
        },
      ]}
    ></AmplifySignUp>
    <div>
      My App
    </div>
  </AmplifyAuthenticator>
);

export default App;

あとはAmplifySignUpを最初の画面の前にプロパティを加えて入れてあげればOK。

slotはAmplifyのUIコンポーネントをカスタマイズするために必要なプロパティ。他にもコンポーネントに合わせたslotがあるので
ここを参考に必要なslot名を入れる。(AmplifySingInならslot="sign-in"といった具合)

usernameAliasは先ほどのSign-in画面のカスタマイズの時と同様、Usernameにメールアドレスを使用可能にするプロパティ。

formFieldsは入力項目をカスタマイズするためのプロパティ。配列の中のオブジェクトによって入力項目を制御できる。

typeで入力項目の種類、labelで入力欄の上に表示される文字、placeholderで入力欄に表示されるプレースホルダー、そしてrequiredで必須項目か否かを指定することができる。

今回はメールアドレスとパスワードの2つの必須項目を設定した。

Sign-up2

これでアカウント作成が可能になったので早速作ってみる。Sign-up画面の項目を入力してCREATE ACCOUNTをクリックすると確認画面が表示される。

Confirm page

登録したメールアドレスに確認用の6桁のコードが送信されるのでそれを入力すれば確認完了。アプリにサインインできるようになる。

サインアウト

これでサインインする準備ができた。サインインできるならサインアウトも必要だ。サインアウトの実装も至って簡単。

App.js
import { AmplifyAuthenticator, AmplifySignUp, AmplifySignOut } from '@aws-amplify/ui-react';

まずはAmplifySignOutを@aws-amplify/ui-reactからインポートする。

App.js
const App = () => (
  <AmplifyAuthenticator usernameAlias="email">
    <AmplifySignUp
      slot="sign-up"
      usernameAlias="email"
      formFields={[
        {
          type: "email",
          label: "Email address",
          placeholder: "Enter your email address",
          required: true,
        },
        {
          type: "password",
          label: "Password",
          placeholder: "Enter your password",
          required: true,
        },
      ]}
    ></AmplifySignUp>
    <div>
      My App
      <AmplifySignOut /> {/* <- ここに追加 */}
    </div>
  </AmplifyAuthenticator>
);

あとは画面の好きなところにを入れてあげれば完成。

Sign out

サインインすると最初の画面に横長なSing-outボタンが表示された。

ボタンの文言を変更したいときは以下のようにbuttonTextプロパティに指定の文言を渡してあげれば変えることができる。

App.js
<AmplifySignOut buttonText="Custom Sign Out Button"/>

Sign out2

(小文字で書いても大文字になっちゃうみたい・・・)

ちょっとだけ問題点

追記(2020/8/3)

コメントにある通り、Amplifyの公式サイトにログイン画面の配置を真ん中にするCSSのテンプレートがあった。
index.cssに以下を記述することでログイン画面が真ん中に表示された。
新コンポーネントを利用する際は忘れずに記載するようにしよう。
(ずっとApp.cssの方に記載して「全然反映されねぇ…」と少し焦ったのは内緒。)

index.css
amplify-authenticator {
  display: flex;
  justify-content: center;
  align-items: center;
  flex: 1;
  height: 100vh;
}

とっても簡単に認証画面周りを構築してくれるAmplify Frameworkの新コンポーネントだが、少しだけ問題点もあった。(※追記で解決済み)

上記では認証コンポーネントのみを切り抜いてスクショしていたのでわからなかったが、実は下のように左上にデフォルトで表示されてしまうのだ。

Sing In3

Legacy版のwithAuthenticatorを使っていた場合だとデフォルトでスクリーンの真ん中に表示されていたが、新バージョンはそこまで気を利かせてはくれないらしい。

IssueもまだOpen状態なので今後改善されるのを待つしかなさそう。

App.js
<AmplifyAuthenticator usernameAlias="email" style={{ textAlign: 'center', margin: 0 }}>

こんな感じでstyleを適用してみても横方向の真ん中に設定できるくらいだった。(・・・ので誰か知恵をお貸しください(ボソッ))

ちなみに新バージョンにもwithAuthenticatorはあるので以下のように使えばサインイン画面を真ん中に表示させることはできる。

App.js
import React from 'react';
import { withAuthenticator, AmplifySignOut } from '@aws-amplify/ui-react';

const App = () => (
  <div>
    <AmplifySignOut />
    My App
  </div>
);

export default withAuthenticator(App);

ただしこれだとAmplifySingUpの入力項目カスタマイズができなかった。(調査不足でできたらゴメンナサイ・・・)

ここら辺のデザイン周りが調整されればあとは完璧かなと感じた。画面のど真ん中にこだわらない方であれば横方向の真ん中までなら配置できるので問題ないはず。

まとめ

Amplify FrameworkはCLIを操作するだけでバックエンド、フロントエンド両方をいい感じに作ってくれる便利なフレームワーク。

新しいUIコンポーネントでも手軽に項目の操作などができ、認証周りの開発はとても捗りそう。

ここで述べた他にもカスタマイズ可能な項目やコンポーネントはたくさんあるので今後も調べながら使ってみたい。

また記事中に何か不足している点などがあれば是非ご指摘いただければ助かります。

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】EC2 MySQL パスワードエラーを解決(Rails アプリデプロイ時)

はじめに

(下準備編)世界一丁寧なAWS解説。EC2を利用して、RailsアプリをAWSにあげるまで
こちらの記事を参考にさせていただき、Rails のオリジナルアプリをAWSを利用しデプロイしようと試みました。

すると、こちらの記事
(デプロイ編②)世界一丁寧なAWS解説。EC2を利用して、RailsアプリをAWSにあげるまで
Ruby

デプロイ編②の「MySQLの設定」でかなり躓いたのでエラー内容と解決した方法を記述する。

エラー内容から解決までの簡単な流れ

ターミナルでEC2インスタンスにログインし、MySQLを起動した状態で

  1. rake db:create RAILS_ENV=productionを実行 → 「パスワードがないから、アクセスできないよ」とエラーがでる
  2. コマンドを実行しパスワードを確認する
  3. 確認したパスワードを database.yml に記述する
  4. 再度rake db:create RAILS_ENV=productionを実行 → 「パスワードが有効期限切れだよ」とエラーがでる
  5. パスワードを変更する
  6. 変更したパスワードを database.yml に記述する
  7. rake db:create RAILS_ENV=production 実行できた!!

以下でもう少し詳細に説明する

解決のためにやったことを説明

1. rake db:create RAILS_ENV=productionを実行

$ rake db:create RAILS_ENV=production
# エラー文
Access denied for user 'root'@'localhost' (using password: NO)

「パスワードがないからアクセスできないよ」と拒否される。

確かに database.yml の production環境記述 password の部分は空欄になっていた

database.yml
production:
  <<: *default
  database: thankshabit_production
  username: root
  password:           # ←ここが空欄

2. コマンドを実行しパスワードを確認する

パスワードがわからないので、こちらのコマンドを実行しパスワードを確認する

$ sudo cat /var/log/mysqld.log | grep 'temporary password'
[Note] A temporary password is generated for root@localhost: XXXXXX

このコマンドを実行し表示された最後の部分「XXXXX」がパスワード。
この部分を database.yml に記述する

3. 確認したパスワードを database.yml に記述する

アプリのディレクトリにいる状態で

$ vi config/database.yml

を実行し、確認したパスワードを database.yml に記載する

database.yml
production:
  <<: *default
  database: thankshabit_production
  username: root
  password: XXXXX # ←ここに記述 

4. 再度rake db:create RAILS_ENV=productionを実行

再度実行したらまた別のエラーがでる

$ rake db:create RAILS_ENV=production
# エラー文
Mysql2::Error: Your password has expired. To log in you must change it using a client that supports expired passwords.

「パスワードが有効期限切れだから、変更する必要がある」と言われている。

5. パスワードを変更する

コマンドを実行し、パスワードを変更する

$ sudo mysql_secure_installation
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MySQL
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!
In order to log into MySQL to secure it, we'll need the current
password for the root user.  If you've just installed MySQL, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.
Enter current password for root (enter for none): 

Enter を押す

OK, successfully used password, moving on...
Setting the root password ensures that nobody can log into the MySQL
root user without the proper authorisation.
Set root password? [Y/n] y

パスワードを設定するかどうか聞かれているため、「y」+「Enter」

New password: 
Re-enter new password: 
Password updated successfully!
Reloading privilege tables..
 ... Success!

新しいパスワードを確認含めて2回入力する
ここで注意なのですが、このパスワードの文字制約がかなり厳しい
筆者はこちらなどを利用して制約をクリアするパスワードを設定した。

Remove anonymous users? [Y/n] y
 ... Success!

Disallow root login remotely? [Y/n] y
 ... Success!

Remove test database and access to it? [Y/n] y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reload privilege tables now? [Y/n] y
 ... Success!
Cleaning up...

全てに「y」+「Enter」で返していく

これでパスワードの新規設定が完了!!

6. 変更後のパスワードを database.yml に記述する

アプリのディレクトリにいる状態で

$ vi config/database.yml

を実行し、先ほど新規に設定したパスワードを記述し直す

database.yml
production:
  <<: *default
  database: thankshabit_production
  username: root
  password: XXXXX # ←ここに新パスワードを記述し直す 

7. rake db:create RAILS_ENV=production 実行

$ rake db:create RAILS_ENV=production 

無事実行できた!!

最後に

無事にこのつまずきを乗り越えてAWSでデプロイできました。色々な記事などを参考にさせていただきRailsアプリを無事にデプロイできました。
DBについてもネットワークやインフラ面についても理解はまだ浅いですが非常に勉強になりました。

参考にさせていただいた記事、サイトには本当に感謝しかないです。
ありがとうございました。

今回エラー解決に参考にさせていただいた記事↓↓ ありがとうございました!!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Route53でドメインを登録した際にNginxのページが表示されてしまう時の対処

経緯

・Railsのアプリケーションは既にAWSへデプロイ済み
・せっかくならIPアドレスのままではなく、独自ドメインで表示したい!

行ったこと

1.お名前.comでドメインを購入。
2.Route53でホストゾーンを作成し、ネームサーバーをお名前.comからRoute53へ変更。
3.レコードセットを作成し、ドメインに紐づくIPアドレスを登録

起こった問題

AWSのコンソール、レジストラ側の設定が全て完了して、いざ取得したドメインで自分のサイトが開ける。と思ったが、Nginxのページが出てしまいアプリケーションへアクセス出来ない。
スクリーンショット 2020-08-02 18.22.25.png

対処

・Nginxの設定で新しいドメインのURLを明記する

EC2へログインして、

[ec2-user@ip-xxxx ~]$ sudo vim /etc/nginx/conf.d/rails.conf
rails.conf
upstream app_server {
  server unix:/var/www/<アプリケーション名>/tmp/sockets/unicorn.sock;
}

server {
  listen 80;
  # ここのElasticIPとなっている箇所を、
  server_name xxx.xxx.xx.xx; 
  # 取得したURLへ変更する
  server_name <取得したドメインのアドレス>; 


  client_max_body_size 2g;

  root /var/www/<アプリケーション名>/public;

  location ^~ /assets/ {
    gzip_static on;
    expires max;
    add_header Cache-Control public;
  }

  try_files $uri/index.html $uri @unicorn;

  location @unicorn {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://app_server;
  }

  error_page 500 502 503 504 /500.html;
}

最後にNginxを起動させて設定ファイルの変更を読み込ませる

[ec2-user@ip-xxxx ~]$ sudo systemctl start nginx
[ec2-user@ip-xxxx ~]$ sudo systemctl reload nginx

あとは、Capistranoを走らせるついでにUnicornを再起動したら、無事に自分のアプリケーションが開けました!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ファイル保存先をS3に設定後、RailsアプリをHerokuにpushすると失敗するエラーについて

エラー発生の経緯

本番環境でファイルを投稿後、1日程経つとファイルが表示されなくなる問題が発生していたため、HerokuへデプロイしていたRailsアプリを更新し、ファイルアップロード先をAWS S3に変更しました。

ローカル環境では適用に成功しましたが、git push heroku masterコマンドで本番環境に適用しようとするとエラーが発生しました。

エラー内容

ターミナル
Caused by:
ArgumentError: key must be 16 bytes

結論

以下のコマンドで環境変数を設定するとエラーが解消されました。
heroku config:set RAILS_MASTER_KEY=`cat config/master.key`

原因

元々下記のようなエラーが出ており、解消のために
heroku config:set RAILS_MASTER_KEY=`rake secret`
と言うコマンドで環境変数を設定していました。

ターミナル
-----> Preparing app for Rails asset pipeline
       Running: rake assets:precompile
       Missing encryption key to decrypt file with. Ask your team for your master key and write it to /tmp/build_6edee55a_/config/master.key or put it in the ENV['RAILS_MASTER_KEY'].
 !
 !     Precompiling assets failed.
 !
 !     Push rejected, failed to compile Ruby app.
 !     Push failed

`rake secret`は secret.yml を使っている場合のコマンドであり、credentials.yml.enc (Rails5.2以降) を使っている場合はRAILS_MASTER_KEY には`cat config/master.key`と設定する必要がありました。

参考:Ask your team for your master key and put it in ENV[“RAILS_MASTER_KEY”] on heroku deploy

解決までに行ったこと

エラー解消方法に気づく直前まで、最後の方で出力されていた以下のようなエラーに注目していました。
出力されている通りPrecompiling assets failedPush rejectedfailed to compile RubyPush rejectedといったワードで検索してエラー解消に奮闘していましたが、解決しませんでした。

ターミナル
remote:        /tmp/build_0a1646cf/vendor/bundle/ruby/2.5.0/gems/sprockets-rails-3.2.1/lib/sprockets/rails/task.rb:62:in `block (2 levels) in define'
remote:        Tasks: TOP => environment
remote:        (See full trace by running task with --trace)
remote: 
remote:  !
remote:  !     Precompiling assets failed.
remote:  !
remote:  !     Push rejected, failed to compile Ruby app.
remote: 
remote:  !     Push failed
remote: Verifying deploy...
remote: 
remote: !       Push rejected to (アプリ名).
remote: 
To https://git.heroku.com/(アプリ名).git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.heroku.com/(アプリ名).git'

エラー解消に繋がらなかった作業

1. heroku git push先を再設定
herokuのリモートリポジトリをセット
 git remote set-url heroku https://git.heroku.com/(アプリ名).git
heroku git push先確認
 git remote -v

2. config/application.rbの設定変更
config/application.rb の config.assets.initialize_on_precompile = trueconfig.assets.initialize_on_precompile = false に変更
参考 RailsでアプリをHerokuにあげる時のエラー各種
   Herokuにpushしたらprecompile assets faild.が。pushできたと思ったらApplication Errorが。解決するまで。

3. assets:precompileの設定変更
RAILS_ENV=production bundle exec rake assets:precompile
参考 Herokuにデプロイしたときの「Precompiling assets failed.」エラーについて

4. buildpackを手動設定してデプロイ
heroku buildpacks:set heroku/ruby
参考 Heroku へのデプロイに参った!

5. Herokuを消して、作り直し
Herokuのアプリ管理画面の Settings → Delete app からアプリを削除
git remote rm heroku でremoteにあるherokuを削除
heroku create (アプリ名) でアプリを作り直す ※アプリ名は元と同じ
git push heroku masterでデプロイ
参考 herokuにデプロイできない

6. 通常にデプロイできていた部分までrevertして再デプロイ
GitHub Desktop の History でコミットを1つずつ右クリックして Revert this Commit

7. 強制プッシュでデプロイ
git push heroku --force master

学んだこと

・ログは上の方もしっかり読む(最後の方のログに惑わされない)
・エラー発生直前に行った作業から原因を推測する(関係の薄いファイルはいじり過ぎない)
credentials.yml.encconfig/master.key、 環境変数の仕組みを理解することが重要
・herokuはアプリを消すと再度同じURLでアプリ作成、デプロイできる
・Git で管理されないファイルを変更したりして環境変数が関わるエラーが発生した際は revert や 再デプロイしても本番環境のエラーは直らない

特にPrecompiling assets failedといったエラーに関する情報は沢山ありますが、原因は様々なため、エラー内容をしっかり見ることが非常に大切だと実感しました。

※最後の方のエラーばかり見て解決に何時間もかかっていましたが
「ArgumentError: key must be 16 bytes」がエラーの本体だと気づいた後、30分もかからずに解決しました!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

WindowsマシンをWinAuthでMFAデバイスにする

WindowsマシンにWinAuthをインストールすることで、多要素認証の仮想MFAデバイス(時間ベースのワンタイムパスワード生成器)として利用できるようにする話。社員に配布しているのはWindowsマシンだけなのだけど、BYODの雰囲気がある私有スマホは業務での多要素認証に使わせたくない、という組織を想定しています。

なぜWinAuthを使うのか

AWS等ではセキュリティ強化のためにMFA(多要素認証)が利用可能で、認証の第二要素として仮想MFAデバイスが利用できます。これは特定の端末上に構成された、TOTP(時間ベースのワンタイムパスワード)ソフトウェアです。一般には各自のスマートフォン上の多要素認証アプリケーション(例えばGoogle AuthenticatorMicrosoft Authenticator)が使われるでしょう。

それを避け、Windows端末を多要素認証用のデバイスとして利用したいという企業(組織)ニーズとして、ここでは以下を想定しました。

  1. 会社貸与のWindowsマシンだけで多要素認証を行わせたい。例えば企業として従業員にスマートフォンは貸与していないが、BYODの仕組みはないので、私有スマートフォンでの認証を避けたい。
  2. 電子機器持込み禁止のエリアで、据置きのWindowsマシンで多要素認証を行わせたい。例えば本番環境への運用作業場所は専用のオペレーションルームなどに限定しており、ここへの電子機器持込みは認めていない。

またWindowsで広く使われるパスワードマネージャー、例えばLast Passwordや1passwordなどもワンタイムパスワード(TOTP)の機能を持ち仮想MFAデバイスとして使えます。これについては、組織として、端末間でデータが同期されるかコピーできるものは多要素認証と認めないことを想定しています。

いろいろと縛りがめんどくさい想定ですが、私の知っている実在環境でも該当するものがあります。こうしたケースを想定した時、以下が要件になります。

  • Windows上で動作する
  • データが端末内で完結し端末外に出ない(端末に紐づく)

WinAuthはこれを満たすものとして選択しました。他にも候補があるかもしれませんが、要件を満たすものがあったことで十分とし、調査比較はしていません。

WinAuthのインストール

WiAuthにAWS MFA仮想デバイス登録

  • 展開されたフォルダ内の WinAuth.exe を実行
  • [Add] > [Authenticator]を選択
    2020-07-16-14-39-31.png
  • 「Add Authenticator」画面の1.の入力欄に、AWSの仮想MFAデバイス登録画面で表示されるコードを貼り付け
    2020-07-16-14-57-18.png
  • Verify Authenticator をクリック
  • AWSの仮想MFAデバイス登録画面に、「Add Authenticator」画面の4.に表示されるコード2回分を貼り付けて登録
  • 「Add Authenticator」画面の OK をクリックして登録
  • 「Protection」画面で以下を実施
    • 「Protect with my own password」にチェックを入れ、「Password」「Verify」に任意のパスワードを入力
    • 「Encrypt to only be useable on this computer」と「And only by the current user on this computer」にチェック
    • OK をクリックして保存
      2020-07-16-14-55-44.png

WinAuthでAWS MFA認証

  • 展開されたフォルダ内の WinAuth.exe を実行
  • 表示された6桁のコードを、AWSの認証画面のMFAコード入力欄に入力
    2020-07-16-15-14-29.png

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSを始めよ-勉強のガイド

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS EC2のDedicated Hostsとハードウェア専有インスタンスの違い

概要

EC2における以下2つの違い。ソリューションアーキテクトの模擬試験などで頻繁に出るが毎回忘れるため自分用メモ。

  • Dedicated Hosts
  • ハードウェア専有インスタンス(Dedicated Instances)

要点

  • Dedicated Hosts、ハードウェア専有インスタンスともにハードウェアを専有できるオプション。
  • Dedicated Hostsはどのハードウェアで起動するかを固定することができる。
  • 一方、ハードウェア専有インスタンスはハードウェアの固定はできない。

用途

  • Dedicated Hostsは、ソフトウェアライセンスがハードウェアに依存する場合やBYOL(Bring Your Own License)で利用。
  • ハードウェア専有インスタンスは、コンプライアンス要件などで他人と異なるサーバで起動する必要がある場合などに利用。

補足

公式ドキュメントにより詳細な違いがある。今回はわかりやすい部分を記載した。
Dedicated Hosts

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む