EC2起動からLaravelプロジェクトのデプロイまで

### 1. elastic ipをインスタンスに割り当て & security groupにhttp追加
-elastic ipをインスタンスに割り当て
-security groupのruleにHTTPを追加

### 2. ssh ログイン
ssh ec2-user@${elastic ip} -i ~/.ssh/***.pem

### 3.ec2-user グループ
$ sudo groupadd www
// ユーザー(ec2-user)を www グループに追加
$ sudo usermod -a -G www ec2-user
$ groups

### 4. rootユーザpass変更
$ sudo su –
$ passwd

### 5. git install
// 省略

### 6. Node.js install
// 省略

### 7. Apache HTTP Server
// 省略

### 8. php 7.3 install
// 省略

### 9. MySQL 8.0 install
// 省略 インスタンスタイプがnanoだとmemory不足となるので要注意

### 10. ansible install
// 省略

### 11. date time変更
// 省略

### 12. *.conf の設置
$ sudo mkdir /var/www/log
$ sudo vi /etc/httpd/conf.d/custom.conf

# エラーログ
ErrorLog "/var/www/log/error_log"

# アクセスログ
<IfModule log_config_module>
    CustomLog "/var/www/log/access_log" combined
</IfModule>

### 13. git clone
$ sudo git clone https://github.com/***/***.git

// ドキュメントルート変更
$ sudo vi /etc/httpd/conf.d/custom.conf

DocumentRoot "/var/www/hoge/public"

# .htaccess 有効化
<Directory /var/www/hoge/public>
    AllowOverride All
</Directory>         

### 14. パーミッション変更
$ sudo chmod -R 777 hoge/storage
$ sudo chmod -R 775 hoge/bootstrap/cache
// /var/www とそのコンテンツのグループ所有権を www グループに変更
$ sudo chown -R root:www /var/www

### 15. project
$ curl -sS https://getcomposer.org/installer | php
$ sudo php composer.phar install
$ sudo php composer.phar dump-autoload
$ sudo php artisan key:generate
// 省略

### 16. Elastic ipにアクセスし、動作確認
http://***/login
http://***/register

EC2の起動からSSH接続までの一連の流れ

### 前提条件
– MFA認証のIAMユーザ作成済
– VPC、public subnet、InternetGateway、RouteTable作成済
– セキュリティグループ作成済
– Key Pairsで秘密鍵・公開鍵作成済

### EC2
1. launch instance
2. Amazon Linux 2 AMI (HVM), SSD Volume Type 64bit(x86)
3. Choose instance type
4. networkで作成したVPC、public subnetを設定(InternetGateway紐付け済)
  Auto-assign Public IPをenableにする disableのままだと、privateしか割り当てられない
5. storage sizeはdefaultの8GiB
6. Add tag: keyにdev, valueにdev-testとする
7. Configure Security Groupで作成したsecurity groupを紐付け(ssh許可)
8. 作成したkey pairを選択
※VPCのDNS resolution、DNS hostnamesがEnabledになっていることを確認。desabledの場合はactionで変更。instanceを再起動

接続

ssh ec2-user@${public ip} -i  ~/.ssh/***.pem

cyberduckでも同様に、ssh-private keyで.pemを指定すると、接続できる。

お、お、お、お疲れ様でしたー

EC2のKey Pairs作成(mac編)

### Key Pairs作成
– EC2のleft paneのNetwork & Security -> Key Pairsを選択
– Create key pair
– Name: aws-dev(file formatはpem)

### macの.sshに保存
$ pwd
/Users/${username}
$ ls -a
$ cd .ssh
$ ls
aws-dev.pem

アクセス権限の変更: オーナーのみ読み出しができる400(所有者:R)
$ sudo chmod 400 aws-dev.pem 
$ ls -l
-r——–@

pemファイルは秘密鍵
流れとしては
1. ssh接続要求
2. aws側でランダムデータを生成し、公開鍵を使ってクライアントに送る
3. 受け取ったクライアント側は秘密鍵でデータを復号化して送り返す
4. aws側でランダムデータと受け取った復号化データを比較して認証する

このような仕組みから、key parisはAWSで生成するのではなく、ローカルマシンでの生成が望ましい。
$ ssh-keygen -t rsa -f hoge.pem

VPCセキュリティグループの作成

セキュリティグループとは?
-> セキュリティグループとはインスタンスに関連付ける仮想ファイアウォール
-> インバウンドトラフィックとアウトバウンドトラフィックを許可する形でルール追加
-> 拒否するルールは設定できない
-> セキュリティグループはsubnetの中

### Security groupの作成
Security group name: dev-security-group
Description: Allow SSH Access
VPC: dev-vpc

Edit inbound rules
Type: SSH
Protocol: TCP
PortRange: 22
Source: MyIP(全てのipを許可する場合は0.0.0.0/0)

VPC、public subnet、InternetGateway、RouteTableの作成

EC2の構成を見ると、VPCの中にsubnetがあり、その中にEC2が入る。
従って、EC2の前にVPC、subnetを作成していく。

1. VPCの作成
CIDR block

2. Subnetの作成
どこと通信できるか設定

3. Route Tableの作成
Subnet間や外部通信用の設定
SubnetとInternet Gatewayの設定

4. Internet Gatewayの作成
インターネットと通信することをRoute Tableに許可
VPCにアタッチして、Route Tableに紐づけ

5. Network ACLの設定
SubnetのInBound(内部への通信)とOutBound(外部への通信)制御の設定

6. Security Groupの設定
インスタンスのInBound(内部への通信)とOutBound(外部への通信)制御の設定

### 1. VPCの作成
name-tag: dev-vcp
IPv4 CIDR block: 192.168.0.0/16 (10.0.0.0/16などでも可)
※「/16」は16個のアドレスができるという意味。ネットマスク
※CIDRとはIPアドレスの記述形式

CIDR block: A.B.C.D/E
AはVPC作成時に設定(内部のルーティング)
BはVPC作成時に設定(内部のルーティング)
EはVPC作成時に設定
CはSubnet作成時に設定(subnetごとに分ける)
DはSubnet作成後に自動設定(Cから自動生成)

VPC作成時に、VPCのトラフィックをルーティングするためのルールを登録する「ルートテーブル」というリソースも作成される

### 2. subnetの作成
name-tag: dev-subnet-public
vpc: dev-vpc
VPC CIDRs: 192.168.0.0/16
IPv4 CIDR block: 192.168.1.0/28

### 3. Internet Gateway
name-tag: dev-igw
作成後、actionでdev-vcpにattach

### 4. RouteTable作成
どのIPアドレス宛の通信をInternet Gatewayにむけるか決める
name-tag: dev-routetable
vpc: dev-vpc

– ルートテーブルにインターネットゲートウェイへのルートを登録する
->ルートの編集
Destination: 0.0.0.0/0
Target: Internet-gateway igw-********
※VPC内宛以外の通信に関してはインターネットゲートウェイに向く

ルートテーブルからサブネットに紐付け
Subnet Associationsタブをクリック

以上で、VPC(dev-vcp)の中にpublic subnet(dev-subnet-public)ができて、RouteTable(dev-routetable)で、Internet Gatewayに紐付けられている状態ができました。

defaultVPCではなく、実際に作ることで、VPC、public subnet、InternetGateway、RouteTableについて、大幅に理解が深まります。

IAMロール(permissons)のポリシー設定手順

開発時におけるステークホルダーのIAMのpermissionsについて考える
手順としては、groupを作成して、次にuserを作成する

### 基本
– 基本的にはサーバーサイドエンジニア以外にはAWSコンソールのアカウントは発行しない
– MFA認証を入れる
– フロントエンドエンジニア、PMはスキル、意欲、プロジェクトによってケースバイケースで検討

## Groupの作成
– set groupで、「dev」グループを作成

## Userの作成
### Access Type
– Programmatic accessとAWS Management Console accessをつける
– 作成した「dev」グループをattachする

### Permission
– 各種 AWS リソースの設定変更作業がある
– IAM の管理権限は与えない
– 自分のPCから aws-cli を使って AWS リソースを管理する

-> 「PowerUserAccess」を付与する
-> IAMのみ参照権限になっている
-> 会社からのアクセスのみを許可する場合、オリジナルのポリシーを作成して json の中に「Conditionエレメント」を記述し、IAM グループに作成したポリシーを割り当て

特定のインスタンスやVPCのみ許可したい場合なども出てくると思うので、PowerUserAccessは現実的でない。

IAMでMFAユーザの作り方

IAMでMFA認証のユーザを作成する手順

## 前準備
### スマホにapp storeもしくはGoogle playからAuthyをインストール

## IAM
### add user
– Set user detailsでUser nameを指定: MFA-user
– Select AWS access typeでProgrammatic accessとAWS Management Console accessにチェック

### add user to group
– 後から設定するので、チェックなしでで進む
– tagsも未設定
– create user

### MFAの設定
– IAMのuserから、’MFA-user’を選択し、「Security credentials」タブの「Sign-in credentials」からAssigned MFA deviceのManageを押下
– Virtual MFA deviceを選択
– 事前に作成しておいたAuthyからQRコードをスキャン
– Authyに表示される6桁の数字をAWSに入力

### Console sign-in linkからテスト
– https://***********.signin.aws.amazon.com/console からログイン
– ユーザ名、パスワードを入力するとMFA認証の画面に遷移する
– Authyを起動し、6桁の数字をinput formに入力
– ログイン完了

なるほど、MFA認証は簡単なのでやっておいた方が良さそうですね。

AWS IAM(Identity and Access Management)

## IAMとは?
Identity and Access Management(IAM) is a web service that enables AWS customers to manage users and user permissions in AWS. You can centrally manage users, security credentials such as key, and permissions that control which AWS resources users can access.

ユーザの仕事の内容に合わせて、IAMのグループ(permissions)を設定する。permissionsのないユーザがログインした場合、permission errorとなる。

## 手順
– ユーザを作成する
– group, permissionを作成する
– groupにユーザを作成する
– groupにadd userする

### Permissions
– アクセス権限
e.g. EC2-Admin, EC2-Support, S3-Support

### Group
Groupに対して、permissions, policyがattachされる
– Groupのpolicyには、Effect, Action resourceがある
– InlinePolicyは通常は1ユーザに対して設定
e.g. Allow CloudWatch, EC2, EC2 Auto Scaling, ELB, ELB v2

### Security credentials
– console sign-in link: https://******.signin.aws.amazon.com/console
– console password:
– Assigned MFA device:
– Access keys:

ソフトウェアのコピーレフトライセンスと非コピーレフト

OSS ライセンスの大まかな違い
– コピーレフトライセンス(GPLなど)の場合、配布者にソースコード公開の義務を負う
– 準コピーレフトライセンス(GNU Lesser General Public Licenseなど)は動的リンクとして使用した場合は、そこ以外の部分にはLGPLライセンスを適応させなくていい
– 非コピーレフトライセンス(MIT, Apache Licenseなど)の場合、成果物のソースコードを公開する義務を負わない(非公開にできる)

### Licenses一覧
– Apache License 2.0
 L 非コピーレフト型ライセンス
 L 著作権表示と免責事項表示の保持を求めている。
 L 使用、商用利用、改変、複製、公開、再配布、改変したものの配布、サブライセンス、アプリケーションへの埋め込み、特許技術の利用は可能
 L Trademarksに商標の使用を許可しない
 L 他のライセンスに比べるとルールが緩め
 L 利用割合 13%
 L Spring, Tomcat, Apache HTTP SERVER

– GNU General Public License v3.0
 L コピーレフト型ライセンス
 L ライセンシの派生物まで同じライセンスを求める
 L ライセンサが配布するOSSをライセンシが他のソフトウェアと組み合わせた場合、 ライセンサはライセンシに組み合わせ先のソフトウェアにまで同じライセンスの適用を要求
 L 著作権表示を保持しなければならない+無保証
 L GPLライセンスのオープンソース・フリーソフトウェアは、誰でも自由に複製・改変・頒布することが許可されている
 L 利用割合 14%
 L MySQL(GPL)

– MIT License
 L 非コピーレフト型ライセンス
 L 再配布時には著作権表示を残す+無保障
 L ザブライセンスや著作権者の許諾に関する内容が細かく記載されている
 L 利用割合 38%

– BSD 2-Clause “Simplified” License
 L 非コピーレフト型ライセンス
 L 再配布時には著作権表示を残す
 L 無保証
– BSD 3-Clause “New” or “Revised” License
 L 非コピーレフト型ライセンス
– Creative Commons Zero v1.0 Universal
 L 「著作権者のクレジット(名前)表記」のみが絶対の条件とされ、他に3つの使用条件を組み合わせる事で、著作権者の希望に沿ったランセンスを明示できる
– Eclipse Public License 2.0
– GNU Affero General Public License v3.0
 L コピーレフト型ライセンス
– GNU General Public License v2.0
 L コピーレフト型ライセンス
– GNU Lesser General Public License v2.1
 L 準コピーレフト型ライセンス
 L 動的リンクとして使用した場合は、そこ以外の部分にはLGPLライセンスを適応させなくていい
 L ライブラリやモジュールによく使用される
– GNU Lesser General Public License v3.0
 L 準コピーレフト型ライセンス
– Mozilla Public License 2.0

ライセンスは非常にセンシティブなところですな。

LaravelのDB::rawのエスケープとSQLインジェクション

SQL Injectionとは?
->アプリケーションが想定しないSQL文を実行させること

公式: https://readouble.com/laravel/6.x/ja/queries.html

rawメソッドはクエリを文字列として挿入するため、SQLインジェクションの脆弱性を生まないように十分気をつけてください。

DB::rawメソッド使用時にはエスケープされない。

 User::where(DB::raw('CONCAT(last_name, first_name)'), 'like', '%'.$text.'%')->get();

mysqlのlike演算子では、% と _ 特別な意味を持つが、DB::rawではエスケープされないので、$textに’%’や’_’が入っていた場合など、SQLインジェクションの脆弱性を生む。
$textの値は、¥%、¥¥、¥_と言うようにエスケープしないといけない。

以下のような使い方の場合は問題なしか。

User::select(DB::Raw('concat(last_name, first_name) as name'), 'id')